I did a bit more digging on this test failure, and I think it's an "infant mortality" case--it looks like creating the large string might be triggering a DOD run which is freeing the hash. Just dumping the hash before and after creating the string demonstrates (by crashing during the second dump):
big = calloc(BIGLEN, sizeof(char)); big = memset(big, 'x', BIGLEN - 1);
new_hash(interpreter, &hash);
dump_hash(interpreter, hash);
key = string_from_cstring(interpreter, big, NULL);
dump_hash(interpreter, hash);
Output:
Hashtable[0/16] Bucket 16: type(0) -> type(0) -> type(0) -> type(0) -> type(0) -> type(0) -> type(0) -> type(0) -> type(0) -> type(0) -> type(0) -> type(0)
Hashtable[0/16] Bucket 16: type(524288) -> Segmentation fault
If I allocate the string before creating the hash, the test passes.
hash_t.patch
Description: Binary data
What's the preferred way to prevent this in tests? I know there are various approaches possible, but I don't know if there is a consensus for how to deal with this in test cases--disabling DOD works but seems a bit heavy handed.
This reminds me of those help-yourself hotel breakfasts where overeager staff whisk your cup away as soon as they see it empty. If you're planning on having seconds and want to keep the same cup, then you've got to keep your eye on it.
Disabling empty cup collection - i.e. a big sign saying "Don't take my cup!" - may seem a bit heavy handed, but it does have the advantage of being explicit.
JEff
On Thursday, September 25, 2003, at 09:23 AM, Jeff Clites wrote:
Hi:
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
