Pike 7.3.45 segfaults when attempting to decode an encode_value()'d program.
Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3096
Reported by James Tyson, Samizdat New Media Solutions james@samizdat.co.nz
The cache in Caudium 1.3 uses the following code to serialise/deserialise data for storage on disk:
string _encode_value( mixed var ) {
return MIME.encode_base64( encode_value( var, master()->Codec() ) );
}
mixed _decode_value( string data ) {
mixed obj;
if ( catch( obj = decode_value( MIME.decode_base64( data ),
master()->Codec() ) ) ) {
return 0;
}
return obj;
}
Which works perfectly with Pike7.2, however seems to be totally broken with pike7.3.
The Pike process seems to backtrace when decoding the data. Here is a GDB backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 20316)]
0x08098bb1 in f_encode_value_canonic ()
(gdb) bt
#0 0x08098bb1 in f_encode_value_canonic ()
#1 0x0809d961 in re_decode ()
#2 0x0809df6f in f_decode_value ()
#3 0x0806ece2 in opcode_F_CALL_BUILTIN ()
#4 0x0837f7a4 in ?? ()
#5 0x0807126e in mega_apply ()
#6 0x0806bf47 in opcode_F_CATCH ()
#7 0x0837f70a in ?? ()
#8 0x0807126e in mega_apply ()
#9 0x0806bf47 in opcode_F_CATCH ()
#10 0x405b85da in ?? ()
#11 0x0807126e in mega_apply ()
#12 0x0806bf47 in opcode_F_CATCH ()
#13 0x405b81d5 in ?? ()
#14 0x08071198 in mega_apply ()
#15 0x08071c47 in apply_svalue ()
#16 0x081436ee in exit_files_efuns ()
#17 0x08093504 in low_backend_once ()
#18 0x08093683 in f_Backend_cq__backtick_28_29 ()
#19 0x0807007c in low_mega_apply ()
#20 0x0806e38f in opcode_F_APPLY_AND_POP ()
#21 0x082d0f3d in ?? ()
#22 0x0807126e in mega_apply ()
---Type <return> to continue, or q <return> to quit---
#23 0x0806bf47 in opcode_F_CATCH ()
#24 0x082d0eb8 in ?? ()
#25 0x08071198 in mega_apply ()
#26 0x08071ba6 in apply ()
#27 0x080c0332 in main ()
#28 0x400c617f in __libc_start_main () from /lib/libc.so.6
(gdb)
Aparently the bytecode interpreter barfs.
In this example the bytecode being read is the userdb module, the encoded data being stored to the disk is "tmtlMCUGEl9zdGF0aWNfbW9kdWxlcy5zeXN0ZW0=" which is obviously incomplete. This seems to only effect the program datatype, as simple mappings, etc seem to work fine, the metadata for this object is being stored using the same procedure and seems to work fine ("tmtlMAEHBgB0eXBlBgR2YXJpYWJsZQYAc2l6ZQgkBgpsYXN0X3JldHJpZXZhbCgGAG5hbWUGDG1v ZHVsZXM6Ly91c2VyZGIGA2V4cGlyZXPIO+dwFgYEX3Byb2dyYW1oBgVyYW1fY2FjaGUPBAYGZGlz a19jYWNoZQ8EBgBoaXRzrwYAaGFzaAYcNTQ5MDMyMjE4ODVkNDU3OTM1NWE4YmJkNmZjM2VjZTkG B2NyZWF0ZV90aW1lyDvnG7Y=")