Re: [perl #24030] [PATCH] hash.t fails on OS X
On Friday, Sep 26, 2003, at 13:04 Europe/Berlin, Jeff Clites wrote:
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 0x6104 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.
0x6104 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 0x6104 in string_transcode (interpreter=0x616400,
src=0x623440, encoding=0x19e43c, type=0x19a6fc, dest_ptr=0x0) at
string.c:552
#1 0x6fbc in string_compare (interpreter=0x616400, s1=0x625cd8,
s2=0x623440) at string.c:949
#2 0x45b0 in find_bucket (interpreter=0x616400, hash=0x6223e0,
head=0, key=0x6816b0) at hash.c:281
#3 0x4a4c in hash_put (interpreter=0x616400, hash=0x6223e0,
key=0x6816b0, value=0xbb50) at hash.c:406
#4 0x2b5c in main (argc=1, argv=0xbc2c) at CrashingTest.c:36
#5 0x27f8 in _start (argc=1, argv=0xbc2c, envp=0xbc34)
at /SourceCache/Csu/Csu-45/crt.c:267
#6 0x2678 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:
9.
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.
0x5f30 in string_transcode ()
(gdb) bt
#0 0x5f30 in string_transcode ()
#1 0x6de8 in string_compare ()
#2 0x43e4 in find_bucket ()
#3 0x4880 in hash_put ()
#4 0x2998 in main ()
#5 0x25a4 in _start (argc=1, argv=0xbdd4, envp=0xbddc)
at /SourceCache/Csu/Csu-45/crt.c:267
#6 0x2424 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
999 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
Re: [perl #24030] [PATCH] hash.t fails on OS X
On Fri, 26 Sep 2003, Leopold Toetsch wrote: Jeff Clites [EMAIL PROTECTED] wrote: What's the preferred way to prevent this in tests? I have put now the test in its own sub. So it should be sure that interpreter-lo_var_ptr (the stack limit for trace_system_stack) is above the auto _hash variable. Another possibility is to use the scheme I implemented in t/src/basic_3. This needs some polishing thow - but it works :-) We might need to shift to this scheme--whatever went in to fix the test caused it to fail on all the tinderboxes this morning. Tinders, for the curious, are at http://tinderbox.perl.org/tinderbox/bdshowbuild.cgi?tree=parrot and we've finally got a reasonably reliable mix of systems running the code. (Though I don't, as yet, have a native Windows w/VS/.NET building parrot right, just the cygwin version) Dan
Re: [perl #24030] [PATCH] hash.t fails on OS X
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: 9. 100_000 chars for the key doesn't seem to be very big. Wher does it fail? Can you debug/back-trace it? 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
Re: [perl #24030] [PATCH] hash.t fails on OS X
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: 9. 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. 0x5f30 in string_transcode () (gdb) bt #0 0x5f30 in string_transcode () #1 0x6de8 in string_compare () #2 0x43e4 in find_bucket () #3 0x4880 in hash_put () #4 0x2998 in main () #5 0x25a4 in _start (argc=1, argv=0xbdd4, envp=0xbddc) at /SourceCache/Csu/Csu-45/crt.c:267 #6 0x2424 in start () And just as I was going to get started on t/src/string.t too. 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
Re: [perl #24030] [PATCH] hash.t fails on OS X
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: 9. 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. 0x5f30 in string_transcode () (gdb) bt #0 0x5f30 in string_transcode () #1 0x6de8 in string_compare () #2 0x43e4 in find_bucket () #3 0x4880 in hash_put () #4 0x2998 in main () #5 0x25a4 in _start (argc=1, argv=0xbdd4, envp=0xbddc) at /SourceCache/Csu/Csu-45/crt.c:267 #6 0x2424 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 999 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
Re: [perl #24030] [PATCH] hash.t fails on OS X
Michael Scott [EMAIL PROTECTED] wrote: Program received signal EXC_BAD_ACCESS, Could not access memory. 0x5f30 in string_transcode () (gdb) bt #0 0x5f30 in string_transcode () Thanks for the backtrace - doesn't help much though. Anyway I've commited a patch to reenable 'debugging' per default, it can be turned off via 'debugging=0' in Configure. Can you please redo the bt after cvs update - thanks. leo
Re: [perl #24030] [PATCH] hash.t fails on OS X
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 0x6104 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.
0x6104 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 0x6104 in string_transcode (interpreter=0x616400, src=0x623440,
encoding=0x19e43c, type=0x19a6fc, dest_ptr=0x0) at string.c:552
#1 0x6fbc in string_compare (interpreter=0x616400, s1=0x625cd8,
s2=0x623440) at string.c:949
#2 0x45b0 in find_bucket (interpreter=0x616400, hash=0x6223e0,
head=0, key=0x6816b0) at hash.c:281
#3 0x4a4c in hash_put (interpreter=0x616400, hash=0x6223e0,
key=0x6816b0, value=0xbb50) at hash.c:406
#4 0x2b5c in main (argc=1, argv=0xbc2c) at CrashingTest.c:36
#5 0x27f8 in _start (argc=1, argv=0xbc2c, envp=0xbc34) at
/SourceCache/Csu/Csu-45/crt.c:267
#6 0x2678 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:
9.
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.
0x5f30 in string_transcode ()
(gdb) bt
#0 0x5f30 in string_transcode ()
#1 0x6de8 in string_compare ()
#2 0x43e4 in find_bucket ()
#3 0x4880 in hash_put ()
#4 0x2998 in main ()
#5 0x25a4 in _start (argc=1, argv=0xbdd4, envp=0xbddc)
at /SourceCache/Csu/Csu-45/crt.c:267
#6 0x2424 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 999
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
[perl #24030] [PATCH] hash.t fails on OS X
# New Ticket Created by Michael Scott # Please include the string: [perl #24030] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=24030 t/src/hash.t test 7 fails on Mac OS X 10.2.6 (gcc 3.3) because BIGLEN is too big: 9. I've made it a bit smaller: 65536. This begs the questions: What is the maximum hash key size? What is the largest STRING? Mike -- attachment 1 -- url: http://rt.perl.org/rt2/attach/65276/48683/18db37/hash_t.patch hash_t.patch Description: hash_t.patch
