On Mon Mar 17 14:56:26 2008, bernhard wrote:
> On So. 16. Mär. 2008, 06:57:31, bernhard wrote:
> > Hi,
> >
> > running 'make fulltest' under Linux leaves me with segfaults for
> > gdbmhast.t.
>
> > This happens only for the computed-goto and for the switched runcore.
> > [EMAIL PROTECTED]:~/devel/Parrot/trunk$ uname -a
> > Linux heist 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686
> > GNU/Linux
>
> The same symptoms show with
> ./parrot -C t/dynpmc/digest_9.pir
> and
> ./parrot -S t/dynpmc/digest_9.pir
I am seeing this with GDBMHash and MD5 too, on both x86 and x86-64
platforms.
% gdb parrot
[snip]
(gdb) run -C t/dynpmc/digest_9.pir
Starting program: /home/paranoid/parrot/parrot -C t/dynpmc/digest_9.pir
[Thread debugging using libthread_db enabled]
[New process 25304]
warning: Lowest section in /usr/lib64/libicudata.so.38 is .hash at
0000000000000190
[New Thread 47559694358496 (LWP 25304)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47559694358496 (LWP 25304)]
0x00002b4159e44b20 in MD5_Init () from /usr/lib/libcrypto.so.0.9.8
(gdb) bt
#0 0x00002b4159e44b20 in MD5_Init () from /usr/lib/libcrypto.so.0.9.8
#1 0x00002b415ab61ad4 in Parrot_MD5_nci_MD5_Init (interp=0x60a010,
pmc=0x9885c0) at ./md5.pmc:114
#2 0x00002b415760bf75 in Parrot_NCI_invoke (interp=0x60a010,
pmc=0x9885c0, next=0x9a97c0) at ./src/pmc/nci.pmc:203
#3 0x00002b41575afa81 in cgp_core (cur_op=0x9a8100, interp=0x60a010) at
src/ops/object.ops:78
#4 0x00002b4157515222 in runops_cgp (interp=0x60a010, pc=0x9a9750) at
src/interpreter.c:776
#5 0x00002b41575154fd in runops_int (interp=0x60a010, offset=0) at
src/interpreter.c:916
#6 0x00002b4157515f80 in runops (interp=0x60a010, offs=0) at
src/inter_run.c:104
#7 0x00002b4157516218 in runops_args (interp=0x60a010, sub=0x988eb8,
obj=0x654fa0, meth_unused=0x0, sig=0x2b41576f7e4b "vP",
ap=0x7fff539bfaf0) at src/inter_run.c:230
#8 0x00002b415751640b in Parrot_runops_fromc_args (interp=0x60a010,
sub=0x988eb8, sig=0x2b41576f7e4b "vP") at src/inter_run.c:299
#9 0x00002b41574fb93e in Parrot_runcode (interp=0x60a010, argc=1,
argv=0x7fff539bfde8) at src/embed.c:941
#10 0x00002b41576d2658 in imcc_run_pbc (interp=0x60a010, obj_file=0,
output_file=0x0, argc=1, argv=0x7fff539bfde8) at compilers/imcc/main.c:794
#11 0x00002b41576d2f57 in imcc_run (interp=0x60a010,
sourcefile=0x7fff539c074a "t/dynpmc/digest_9.pir", argc=1,
argv=0x7fff539bfde8) at compilers/imcc/main.c:1080
#12 0x0000000000400b45 in main (argc=1, argv=0x7fff539bfde8) at
src/main.c:56
(gdb) up
#1 0x00002b415ab61ad4 in Parrot_MD5_nci_MD5_Init (interp=0x60a010,
pmc=0x9885c0) at ./md5.pmc:114
114 (void)MD5_Init(c);
(gdb) print c
$1 = (MD5_CTX *) 0x0
(gdb)
When run without -C or -S, the "c" pointer is non-null and execution
proceeds normally.
For the gdbmhash_3.pir test, the pointer is not null (otherwise the
null-check in the pmc sources would catch it), but it seems to point to
corrupt data. gdbm.h takes measures to prevent introspection , but the
first integer in the fake array is a pointer to the filename, which is
what I'm testing below.
Here's what it looks like with the default runcore:
149 for (key = gdbm_firstkey(dbf); key.dptr; key =
nextkey) {
(gdb) print *dbf
$2 = {dummy = {136637904, 3, 1, 0, 0, 1, 0, 6, 136580112, 136584216}}
(gdb) print (char*)136637904
$3 = 0x824edd0 "gdbm_hash_1"
And here's what it looks like with the CGP runcore:
149 for (key = gdbm_firstkey(dbf); key.dptr; key =
nextkey) {
(gdb) print *dbf
$5 = {dummy = {136521688, 0, 524288, 0, 0, 0, 0, 136521716, 0, 512}}
(gdb) print (char*)136521688
$6 = 0x82327d8 "'#\b"
Mark
