[plt-scheme] mzscheme 4.1.5 segfault

Hello all,
 so after having ported sqlid to mzscheme 4.1.5, I still have a
segfault.
 This is a not very big web application running in plt-web-server, using
sqlid/postgresql and sxml2.0. It receives requests as POST data, makes
queries to the DB, and responds with query results in XML.
 I have a reproducible segfault when serving large bunches of result
data.

 A gdb backtrace is at the bottom.

 Current platform is:
Linux eris 2.6.27-11-generic #1 SMP Wed Apr 1 20:57:48 UTC 2009 i686 GNU/Linux

 I had the same segfault problem with mzscheme 372 (this is why I just
moved to 4.1.5).

 So, does anyone have an idea? What other information could I gather or
provide for help?

Thanks,
 Mate



This is what it looks like in gdb:

Program received signal SIGSEGV, Segmentation fault.
try_channel (sema=0xb6396fb0, syncing=0xb6396fe8, pos=-1, result=0x0)
    at ./../src/sema.c:550
550               w->picked = 1;
(gdb) bt
#0  try_channel (sema=0xb6396fb0, syncing=0xb6396fe8, pos=-1, result=0x0)
    at ./../src/sema.c:550
#1  0x08164a73 in channel_put_ready (ch=0xb6396fb0, sinfo=0xbfe7cd2c)
    at ./../src/sema.c:1008
#2  0x081b1ffb in syncing_ready (s=0xb6396fe8, sinfo=0xbfe7cdb8)
    at ./../src/thread.c:5477
#3  0x081b1cf4 in scheme_block_until (_f=0x81b1ed0 <syncing_ready>, 
    fdf=0x81aa1f0 <syncing_needs_wakeup>, data=0xb6396fe8, delay=0)
    at ./../src/thread.c:4249
#4  0x081b2e6c in do_sync (name=0x81fe326 "sync", argc=1, argv=0xb6ca4e9c, with_break=0, 
    with_timeout=0, _tailok=1) at ./../src/thread.c:5792
#5  0x081b337d in sch_sync (argc=1, argv=0xb6ca4e9c) at ./../src/thread.c:5878
#6  0xb7aafaea in ?? ()
#7  0xb7aafe06 in ?? ()
#8  0xb7aafc22 in ?? ()
#9  0xb7aaf45a in ?? ()
#10 0xb7aaf45a in ?? ()
#11 0xb7aaf07a in ?? ()
#12 0xb7aaf07a in ?? ()
#13 0x08088739 in scheme_do_eval (obj=0xb68b64f8, num_rands=2, rands=0xb6ca4fb0, 
    get_value=-1) at ./../src/eval.c:7918
#14 0x08089cf2 in _scheme_apply_multi_from_native (rator=0xb6cac7a0, argc=-1075327932, 
    argv=0x0) at ./../src/schnapp.inc:70
#15 0xb7ab735a in ?? ()
#16 0x08088739 in scheme_do_eval (obj=0xb68c5858, num_rands=0, rands=0x0, get_value=-1)
    at ./../src/eval.c:7918
#17 0x080a5716 in apply_k () at ./../src/fun.c:2233
#18 0x080af220 in scheme_top_level_do_worker (k=0x80a5690 <apply_k>, eb=1, new_thread=1, 
    dyn_state=0x0) at ./../src/fun.c:2072
#19 0x080af9b6 in scheme_apply_thread_thunk (rator=0xb68c5858) at ./../src/fun.c:2271
#20 0x081b0a1d in start_child (child=0xb68c5b88, child_eval=0xb68c5858)
    at ./../src/thread.c:2862
#21 0x081b5b89 in make_subprocess (child_thunk=0xb68c5858, child_start=0xbfe7d634, 
    config=0xb68c0728, cells=0xb68c5880, break_cell=0xb68c0740, mgr=0x0, normal_kill=1)
    at ./../src/thread.c:2951
#22 0x081b5d93 in scheme_thread_w_details (thunk=0x4, config=0xbfe7d690, 
    cells=0xbfe7d694, break_cell=0xbfe7d6ac, mgr=0xbfe7d6a4, suspend_to_kill=0)
    at ./../src/thread.c:3173
#23 0xbfe7d758 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)