Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] suggestion for record pattern matching and construction
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2003-09-12 (06:34)
From: Gerd Stolpmann <info@g...>
Subject: Re: [Caml-list] FreeBSD + lablglut + thread: bug or not bug
Am Fre, 2003-09-12 um 07.57 schrieb Christophe Raffalli:
> I was wrong to say other multi-threaded code work: here is a stack of
> a crashed kcontrol ...

I would not conclude that from this stack trace. libc_r is a user-level
multi-threading emulation, and many system calls (such as "poll" here)
are redefined to get the effect of the emulation. Maybe the code crashes
in __sys_poll because kcontrol called "poll" with an invalid pointer; a
userland threading library cannot check whether addresses are valid like
the kernel does for real system calls.

Concerning the stability of libc_r I found the bug that the signal mask
is not restored after the signal routine has finished execution. For
most multi-threaded applications this is not a big problem: They usually
do not define signal handlers at all, because this has the disadavantage
that it is undefined in which thread the signal handler runs. Instead,
there is often a separate thread that watches for signals (sigsuspend).
However, O'Caml relies on correct signal semantics, especially for
multi-threaded applications, because it uses an alarm timer to implement
its own time-sharing policy. Consider O'Caml as a "stress test" for the
multi-threading implementation.


> .....
> (no debugging symbols found)...(no debugging symbols found)...
> (no debugging symbols found)...(no debugging symbols found)...
> (no debugging symbols found)...0x28ec256c in __sys_poll ()
>     from /usr/lib/
> #0  0x28ec256c in __sys_poll () from /usr/lib/
> #1  0x28ec1ab8 in _thread_kern_sched_state_unlock () from 
> /usr/lib/
> #2  0x28ec147d in _thread_kern_scheduler () from /usr/lib/
> #3  0x0 in ?? ()
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: