In case it helps, it looks like it's crashing at string.c:552, because it's trying to call src->encoding->decode() but src->encoding is NULL.
(gdb) f 0
#0 0x00006104 in string_transcode (interpreter=0x616400, src=0x623440, encoding=0x19e43c, type=0x19a6fc, dest_ptr=0x0) at string.c:552
552 UINTVAL c = src->encoding->decode(srcstart);
(gdb) l
547 srcend = srcstart + src->bufused;
548 deststart = dest->strstart;
549 destend = deststart;
550
551 while (srcstart < srcend) {
552 UINTVAL c = src->encoding->decode(srcstart);
553
554 if (transcoder1)
555 c = transcoder1(src->type, dest->type, c);
556 if (transcoder2)
(gdb) p encoding
$1 = (const struct parrot_encoding_t *) 0x19e43c
(gdb) p src
$2 = (struct parrot_string_t *) 0x623440
(gdb) p src->encoding
$3 = (const struct parrot_encoding_t *) 0x0
Here's another backtrace, with a little more info:
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x00006104 in string_transcode (interpreter=0x616400, src=0x623440, encoding=0x19e43c, type=0x19a6fc, dest_ptr=0x0) at string.c:552
552 UINTVAL c = src->encoding->decode(srcstart);
(gdb) bt
#0 0x00006104 in string_transcode (interpreter=0x616400, src=0x623440, encoding=0x19e43c, type=0x19a6fc, dest_ptr=0x0) at string.c:552
#1 0x00006fbc in string_compare (interpreter=0x616400, s1=0x625cd8, s2=0x623440) at string.c:949
#2 0x000045b0 in find_bucket (interpreter=0x616400, hash=0x6223e0, head=0, key=0x6816b0) at hash.c:281
#3 0x00004a4c in hash_put (interpreter=0x616400, hash=0x6223e0, key=0x6816b0, value=0xbffffb50) at hash.c:406
#4 0x00002b5c in main (argc=1, argv=0xbffffc2c) at CrashingTest.c:36
#5 0x000027f8 in _start (argc=1, argv=0xbffffc2c, envp=0xbffffc34) at /SourceCache/Csu/Csu-45/crt.c:267
#6 0x00002678 in start ()
JEff
On Thursday, September 25, 2003, at 08:22 AM, Michael Scott wrote:
On Thursday, Sep 25, 2003, at 16:06 Europe/Berlin, Michael Scott wrote:
On Thursday, Sep 25, 2003, at 13:20 Europe/Berlin, Leopold Toetsch wrote:
Michael Scott <[EMAIL PROTECTED]> wrote:
t/src/hash.t
test 7 fails on Mac OS X 10.2.6 (gcc 3.3) because BIGLEN is too big: 99999.
100_000 chars for the key doesn't seem to be very big. Wher does it fail? Can you debug/back-trace it?
(gdb) r Starting program: /Users/mike/Developer/Parrot/Tests/mem_test Reading symbols for shared libraries . done
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x00005f30 in string_transcode ()
(gdb) bt
#0 0x00005f30 in string_transcode ()
#1 0x00006de8 in string_compare ()
#2 0x000043e4 in find_bucket ()
#3 0x00004880 in hash_put ()
#4 0x00002998 in main ()
#5 0x000025a4 in _start (argc=1, argv=0xbffffdd4, envp=0xbffffddc) at /SourceCache/Csu/Csu-45/crt.c:267
#6 0x00002424 in start ()
And just as I was going to get started on t/src/string.t too.
I'm running tests on string_compare and string_transcode with 9999999 byte strings without complaint.
I've made it a bit smaller: 65536.
This begs the questions:
What is the maximum hash key size? What is the largest STRING?
There are no limits except those imposed by UINTVAL (2^32-1) AFAIK.
Mike
leo
