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

More GC Errors (New, Improved, In Senora GC!)



Trying a different approach, I compiled my libmzscheme.a/libgc.a against
the SenoraGC to see if anything different would happen.

Now I see this:

[28/Dec/2000:18:27:20][5880.5126][-nssock-] Notice: nssock: listening on http://hopper (127.0.0.1:80)
[28/Dec/2000:18:27:20][5880.5126][-nssock-] Notice: nssock: accepting connections

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 4101 (LWP 5887)]

do_malloc (set_no=0, size=1075175752, common=0x4037b580, othersptr=0x4037b980, 
    flags=0) at ./sgc.c:2442
    2442          *p = 0;
(gdb) list
2437    
2438      if (!(flags & do_malloc_ATOMIC)) {
2439        void **p = (void **)s;
2440        unsigned long sz = size >> LOG_PTR_SIZE;
2441        for (; sz--; p++)
2442          *p = 0;
2443      }
2444    
2445    #if CHECK_WATCH_FOR_PTR_ALLOC
2446      if (s == UNHIDE_WATCH(GC_watch_for_ptr)) {
(gdb) p s
$3 = (void *) 0x4037d028
(gdb) p size
$4 = 1075175752
(gdb) p size >> 2
$5 = 268793938
(gdb) p sz
$6 = 263054427
(gdb) p (size >> 2) - sz
$7 = 5739511
(gdb) p p
$8 = (void **) 0x41962000
(gdb) p s+sz
$9 = (void *) 0x4fe5b483
(gdb) bt
#0  do_malloc (set_no=0, size=1075175752, common=0x4037b580, 
    othersptr=0x4037b980, flags=0) at ./sgc.c:2442
#1  0x40360bbb in GC_malloc (size=28) at ./sgc.c:2523
#2  0x4034c92e in add_finalizer (v=0x81d1038, 
    f=0x40343f6c <adjust_manager_family>, data=0x0, prim=1, ext=0, 
    ext_oldf=0x0, ext_olddata=0x0, _fns=0x0, _fn=0x0, no_dup=0)
    at ./salloc.c:472
#3  0x4034cad9 in scheme_add_finalizer (p=0x81d1038, 
    f=0x40343f6c <adjust_manager_family>, data=0x0) at ./salloc.c:571
#4  0x403440ec in scheme_make_manager (parent=0x0) at ./process.c:752
#5  0x403464b4 in make_initial_config () at ./process.c:2749
#6  0x4034450a in make_process (after=0x0, config=0x0, mgr=0x0)
    at ./process.c:1033
#7  0x40344774 in scheme_make_process () at ./process.c:1164
#8  0x40316b62 in scheme_basic_env () at ./env.c:256
#9  0x40316274 in Run (arg=0x8193d68) at ns_interps.cc:161
#10 0x81190bb in NsThreadMain (arg=0x81a45d0) at thread.c:241
#11 0x4002dcb5 in pthread_start_thread () from /lib/libpthread.so.0
#12 0x4002dcfd in pthread_start_thread_event () from /lib/libpthread.so.0
			
Frankly, I'm not sure what this routine is trying to do.  Based on
the logging messages I'm getting, it's happening when the new 
"Scheme Server" thread starts up and creates its environment.

If I run in the debugger, you get what I list above.  If I run it
under the OS, I get an "out of memory" error when "scheme_basic_env"
is called.  This isn't exactly surprising, since according to the
debugger it's attempting to allocate close to 1 Gig of memory,
and I doubt I have enough RAM and swap to accommodate that.

So, it looks like I'm stuck.  Do I have to set up an entirely separate
server *process* to handle any scheme activities, and communicate
via IPC of some kind between the webserver and MzScheme?  If true,
this is a bit of a bad limitation in MzScheme's embedibility.  :-)

Let me know if there's anywhere I can look to help you guys out.
I'm wondering if I'm running into a similar problem to Guile's
need for it to hold the "main" thread, while running the "main"
program in some subservient thread...

Any ideas?

-Brent