txr-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Txr-users] txr segfaults on startup, Mac OSX 10.6


From: Andy Wildenberg
Subject: Re: [Txr-users] txr segfaults on startup, Mac OSX 10.6
Date: Mon, 5 Dec 2011 23:12:16 -0700

My question is: has any version of TXR worked for you before, or are
you a first timer? From your other comments I'm guessing.

Yes, first time.  If there was a more stable version to work from, I'd be happy to oblige, but I didn't see anything marked in that way.

Can you post your config.make, and more importantly config.h?

Included.  config.h looks pretty suspicious when it does a 1 << 78 while building INT_PTR_MAX.  You know what a more reasonable value would be?  62?  I was looking for problems in the Makefile -- I forgot that autoconf builds config.h as well...

If I drop it to 1 << 60 it passes 'make tests'.  I'm guessing this means that in some high-stress situations it may cause the gc to barf somehow?

So the short answer is that I now have a functional txr that's good enough to pass the basic tests, so I can get started developing txr scripts.  However, I'll include the answers to the rest of your questions below in the hopes that it'll help you with the autoconf stuff.  I'm happy to be a guinea pig on this -- my full make is very fast and I can build it in /tmp so it's no skin off my back to do configure; make cycles for you.

Thank you,

Andy


It's possible that something is not configured properly.
I have a hard time believing that the length of a string is
not in the range NUM_MIN to NUM_MAX, even in this recursive
fault.

Perhaps NUM_MIN and NUM_MAX are themselves garbage.

Correct behavior starts with a sane build configuration.

Here are some more stack traces after disabling optimization:

w/o break on uw_throwf:

#0  0x000000010002a697 in uw_throwf (sym=Cannot access memory at address 0x7fff5f3fff88
) at unwind.c:290
#1  0x000000010001c9d6 in num (n=1) at lib.c:791
#2  0x000000010001dabc in length_str (str=0x7fff5f400123) at lib.c:1178
#3  0x000000010002b91a in string_out_put_string (stream=0x100232b88, str=0x7fff5f400123) at stream.c:409
#4  0x000000010002ba61 in string_out_put_char (stream=0x100232b88, ch=0x186) at stream.c:435
#5  0x000000010003044d in put_char (stream=0x100232b88, ch=0x186) at stream.c:1105
#6  0x000000010002c9c3 in vformat (stream=0x100232b88, fmtstr=0x1000480eb, vl=0x7fff5f4002e0) at stream.c:845
#7  0x000000010002a77e in uw_throwf (sym=0x0, fmt=0x1000480eb) at unwind.c:295
#8  0x000000010001c9d6 in num (n=1) at lib.c:791
#9  0x000000010001dabc in length_str (str=0x7fff5f400473) at lib.c:1178
#10 0x000000010002b91a in string_out_put_string (stream=0x100232ba8, str=0x7fff5f400473) at stream.c:409
<snip>

**** ***** after adding break on uw_throwf **** ***** 
note: obviously I can do some debugging at this point, but since it seems that the INT_PTR_MAX definition has fixed the problem, I stopped.  Happy to go back in if necessary.

#0  uw_throwf (sym=0x0, fmt=0x1000480eb) at unwind.c:292
#1  0x000000010001c9d6 in num (n=256) at lib.c:791
#2  0x00000001000310bf in make_hash (weak_keys=0x0, weak_vals=0x0, equal_based=0x100048bfb) at hash.c:251
#3  0x000000010001ecb2 in make_package (name=0x100049067) at lib.c:1553
#4  0x0000000100022c8a in obj_init () at lib.c:2909
#5  0x0000000100024c6b in init (pn=0x100100080, oom=0x100001414 <oom_realloc_handler>, stack_bottom=0x7fff5fbff768) at lib.c:3254
#6  0x00000001000016a9 in main (argc=3, argv=0x7fff5fbff790) at txr.c:159
(gdb) 

Attachment: config.h
Description: Text Data

Attachment: config.make
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]