[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GC Errors in Embedded Program
On Fri, Dec 29, 2000 at 05:44:10AM -0800, Matthew Flatt wrote:
> With the GC upgrade (version 103.4), I see that the stack-base routine
> changed for x86 Linux. Now it will always find the base of the main
> thread's stack.
>
> If the Boehm GC supports threads for your platform, then you might be
> able to fix the problem by turning on an appropriate compilation flag.
> (For Linux, it's either -DLINUX_THREADS or -DGC_LINUX_THREADS,
> depending on which version of the GC you have.)
>
Bah!
Unfortunately, this doesn't seem to help much either:
[29/Dec/2000:21:38:22][9636.1024][-main-] Notice: nsmain: AOLserver/3.2 running
[29/Dec/2000:21:38:22][9636.1024][-main-] Notice: nsmain: security info: uid=103, euid=103, gid=33, egid=33
[29/Dec/2000:21:38:22][9636.2051][-sched-] Notice: sched: starting
[29/Dec/2000:21:38:22][9636.3076][-socks-] Notice: sockcallback: thread starting
[29/Dec/2000:21:38:22][9636.4101][-nssock-] Notice: nssock: starting
[29/Dec/2000:21:38:22][9636.4101][-nssock-] Notice: nssock: listening on http://hopper (127.0.0.1:80)
[29/Dec/2000:21:38:22][9636.4101][-nssock-] Notice: nssock: accepting connections
Program received signal SIGINT, Interrupt.
[Switching to Thread 1024 (LWP 9636)]
0x4008624a in sigsuspend () from /lib/libc.so.6
(gdb) info thread
6 Thread 4101 (LWP 9643) 0x4011b7de in select () from /lib/libc.so.6
5 Thread 3076 (LWP 9642) 0x4011b7de in select () from /lib/libc.so.6
4 Thread 2051 (LWP 9641) 0x400fc0c1 in nanosleep () from /lib/libc.so.6
3 Thread 1026 (LWP 9640) 0x4011b7de in select () from /lib/libc.so.6
2 Thread 2049 (LWP 9639) 0x40119cb0 in poll () from /lib/libc.so.6
* 1 Thread 1024 (LWP 9636) 0x4008624a in sigsuspend () from /lib/libc.so.6
(gdb) break MV_InterpreterPool::Eval
Breakpoint 1 at 0x4031d678: file ns_interps.cc, line 265.
(gdb) c
Continuing.
[New Thread 5126 (LWP 9650)]
[29/Dec/2000:21:38:46][9636.5126][-conn0-] Debug: serv: starting: waiting for connections
[29/Dec/2000:21:38:46][9636.5126][-conn0-] Debug: MV_PageGet: url /test.ss
[Switching to Thread 5126 (LWP 9650)]
Breakpoint 1, MV_InterpreterPool::Eval (this=0x815c5f8, conn=0x81dbc38,
s=0x4037a203 "(+ 1 2)") at ns_interps.cc:265
265 MV_request* req = new MV_request(eEvalCharCurrent language: auto; currently c++
(gdb) n
266 Ns_Log(Notice, "MachV: Handle a request...");
(gdb) p *reg
$1 = {rxpos (int, int *)} 0x403551c8 <reg>
(gdb) p eEvalCharStr
$2 = eEvalCharStr
(gdb) p s
$3 = 0x4037a203 "(+ 1 2)"
(gdb) n
[29/Dec/2000:21:39:15][9636.5126][-conn0-] Notice: MachV: Handle a request...
267 Scheme_Object* exn = NULL;
(gdb) n
268 Scheme_Object* curerr = scheme_get_param(scheme_config, MZCONFIG_ERROR_PORT);
(gdb) step
0x40350ed2 in scheme_pthread_get_current_process () at ./process.c:3703
3703 return (Scheme_Process *)pthread_getspecific(cp_key);
Current language: auto; currently c
(gdb) p cp_key
$4 = 2
(gdb) step
Program received signal SIGSEGV, Segmentation fault.
0x4031d6d2 in MV_InterpreterPool::Eval (this=0x815c5f8, conn=0x81dbc38,
s=0x4037a203 "(+ 1 2)") at ns_interps.cc:268
268 Scheme_Object* curerr = scheme_get_param(scheme_config, MZCONFIG_ERROR_PORT);
===================================================================
So, I don't know. I'm kind of at a loss for what else to do at
this point. It looks like MzScheme may only work if it stays
under the control of "-main-". It seems to really *hate* being
a subservient thread. Even under Linux with LINUX_THREADS and
REENTRANT.
On that subject, I had to make a few modifications to the CVS sources
to get a compile with todays CVS:
diff -war portfun.c.old portfun.c
725c725
< static do_unlock_mutx(void *m)
---
> static do_unlock_mutex(void *m)
I'm not sure on this section -- this seems more in keeping with the
way this was coded in all the other source files (plus it allows it
to compile...):
diff -war stxobj.c.old stxobj.c
1148c1148
< # ifndef MZ_REAL_THREADS
---
> # ifdef MZ_REAL_THREADS
1469c1469
< # ifndef MZ_REAL_THREADS
---
> # ifdef MZ_REAL_THREADS
In gc/linux_threads.c there are some missing "extern" function
declarations, as well as a "fully_initialized" variable that
never gets set if "THREAD_LOCAL_ALLOC" is unset (which is the
case according to configure on my Linux system).
diff -war linux_threads.c.old linux_threads.c
69a70,73
> extern GC_bool GC_collection_in_progress();
> extern void GC_free_inner(GC_PTR p);
> static GC_bool fully_initialized = FALSE;
>
214,215d217
<
< static GC_bool fully_initialized = FALSE;
Finally, the Makefile has to be changed so that the "threadlibs" utility
is built properly (i.e., with -DLINUX_THREADS or whatnot):
diff -war Makefile.old Makefile
27c27
< CFLAGS= $(BASEFLAGS) $(OPTIONS) -DNO_EXECUTE_PERMISSION -DSILENT -DOLD_BLOCK_ALLOC -DLARGE_CONFIG
---
> CFLAGS= -g $(BASEFLAGS) $(OPTIONS) -DNO_EXECUTE_PERMISSION -DSILENT -DOLD_BLOCK_ALLOC -DLARGE_CONFIG
34c34
< HOSTCFLAGS=$(BASEFLAGS)
---
> HOSTCFLAGS=$(BASEFLAGS) $(OPTIONS)
So, hopefully this is helpful. I'm going to try the Senora GC one more
time for fun, and see how it goes.
Thanks,
-Brent