On Mon, May 09, 2011 at 06:33:14PM +0200, Svante Signell wrote:
Continuing the struggle with the ghc and ruby build problems I stumbled
into finding two kernel (signal) threads in addition to the main (user)
thread. According to Neal on IRC there shouldn't be more than one kernel
thread
On Tue, 2011-05-10 at 10:11 +0200, Richard Braun wrote:
On Mon, May 09, 2011 at 06:33:14PM +0200, Svante Signell wrote:
Continuing the struggle with the ghc and ruby build problems I stumbled
into finding two kernel (signal) threads in addition to the main (user)
thread. According to Neal
On Tue, May 10, 2011 at 10:53:00AM +0200, Svante Signell wrote:
On Tue, 2011-05-10 at 10:11 +0200, Richard Braun wrote:
What makes you think there are two signal threads ?
Did you look at the pasted output?
Are you serious asking that ?
I would call threads 5 and 6 signal
threads and
On Tue, 2011-05-10 at 11:02 +0200, Richard Braun wrote:
On Tue, May 10, 2011 at 10:53:00AM +0200, Svante Signell wrote:
On Tue, 2011-05-10 at 10:11 +0200, Richard Braun wrote:
What makes you think there are two signal threads ?
Did you look at the pasted output?
Are you serious
On Tue, May 10, 2011 at 11:13:29AM +0200, Svante Signell wrote:
Sorry, but your question was not referring to the pasted code at all,
just a direct question. You know better than me of course, I'm just
trying to understand things and admittedly do some guess work.
I wonder what else it could
Yes. Timers do create new threads to wait for the event in question, and
then they send the signal in the normal way.
On May 10, 2011 11:18 AM, Richard Braun rbr...@sceen.net wrote:
On Mon, 2011-05-09 at 18:43 +0200, Samuel Thibault wrote:
Svante Signell, le Mon 09 May 2011 18:33:14 +0200, a écrit :
Single stepping in msgserver.c also triggered the console printout: task
5040ee18 deallocating an invalid port 340/xxx, most probably a bug.
Note that you can make the
Svante Signell, le Tue 10 May 2011 11:38:08 +0200, a écrit :
On Mon, 2011-05-09 at 18:43 +0200, Samuel Thibault wrote:
Svante Signell, le Mon 09 May 2011 18:33:14 +0200, a écrit :
Single stepping in msgserver.c also triggered the console printout: task
5040ee18 deallocating an invalid
On Tue, 2011-05-10 at 11:39 +0200, Samuel Thibault wrote:
Svante Signell, le Tue 10 May 2011 11:38:08 +0200, a écrit :
On Mon, 2011-05-09 at 18:43 +0200, Samuel Thibault wrote:
Svante Signell, le Mon 09 May 2011 18:33:14 +0200, a écrit :
Single stepping in msgserver.c also triggered
Svante Signell, le Tue 10 May 2011 11:50:46 +0200, a écrit :
On Tue, 2011-05-10 at 11:39 +0200, Samuel Thibault wrote:
Svante Signell, le Tue 10 May 2011 11:38:08 +0200, a écrit :
On Mon, 2011-05-09 at 18:43 +0200, Samuel Thibault wrote:
Svante Signell, le Mon 09 May 2011 18:33:14 +0200,
On Tue, 2011-05-10 at 11:56 +0200, Samuel Thibault wrote:
or use nm
on the gnumach binary to get its adress, e.g. 0x20001234, and use
Are you referring to /boot/gnumach-1.3.99-486.gz now, or
/lib/libmachuser-2.11.2.so
In the first case the image is compressed.
The former.
On Mon, 2011-05-09 at 18:43 +0200, Samuel Thibault wrote:
Single stepping in msgserver.c also triggered the console printout: task
5040ee18 deallocating an invalid port 340/xxx, most probably a bug.
Note that you can make the kernel start the in-kernel debugger in that
case. Simply set
On Tue, May 10, 2011 at 11:18:21AM +0200, Richard Braun wrote:
I'll check how glibc deals with POSIX timers. It could simply be that
timer_create() is called with SIGEV_THREAD.
The invalid memory address is likely garbage at the top of the stack.
I wouldn't worry about it.
So, after a quick
Svante Signell, le Tue 10 May 2011 12:02:29 +0200, a écrit :
On Tue, 2011-05-10 at 11:56 +0200, Samuel Thibault wrote:
or use nm
on the gnumach binary to get its adress, e.g. 0x20001234, and use
Are you referring to /boot/gnumach-1.3.99-486.gz now, or
Svante Signell, le Tue 10 May 2011 12:31:16 +0200, a écrit :
On Mon, 2011-05-09 at 18:43 +0200, Samuel Thibault wrote:
Single stepping in msgserver.c also triggered the console printout: task
5040ee18 deallocating an invalid port 340/xxx, most probably a bug.
Note that you can make
Richard Braun, le Tue 10 May 2011 12:41:24 +0200, a écrit :
Also, in your original post, you mentioned finding kernel threads in
addition to the main thread. You *can't* see kernel threads with gdb.
Kernel threads run in the kernel. What you saw are really user space
threads.
I guess he meant
On Tue, 2011-05-10 at 13:34 +0200, Samuel Thibault wrote:
It's not so simple as you say: I have now found out where the
mach_port_deallocate_debug variable is in gnumach-1.3.99-486-dbg (copied
from boot and uncompressed). I have two alternatives:
1) Write a one into that address
Samuel Thibault, le Tue 10 May 2011 13:34:07 +0200, a écrit :
2) Uncompress it at /boot
Start the debugger with C-A-d. Does this work on an uncompressed image?
w 002c10c0 1
cont
There's a misunderstanding: w writes in the living kernel and has
immediate non-permanent effect, not in
Svante Signell, le Tue 10 May 2011 14:00:07 +0200, a écrit :
On Tue, 2011-05-10 at 13:34 +0200, Samuel Thibault wrote:
It's not so simple as you say: I have now found out where the
mach_port_deallocate_debug variable is in gnumach-1.3.99-486-dbg (copied
from boot and uncompressed).
On Tue, 2011-05-10 at 14:06 +0200, Samuel Thibault wrote:
...
Well objdump gave a lot of hits for mach_port_deallocate but
mach_port_deallocate_debug was not found. And the addresses are
different from the hex editor. Anyway using objdump -D I found it:
002c10c0
Svante Signell, le Tue 10 May 2011 14:23:13 +0200, a écrit :
On Tue, 2011-05-10 at 14:06 +0200, Samuel Thibault wrote:
...
Well objdump gave a lot of hits for mach_port_deallocate but
mach_port_deallocate_debug was not found. And the addresses are
different from the hex editor. Anyway
On Tue, 2011-05-10 at 14:27 +0200, Samuel Thibault wrote:
Svante Signell, le Tue 10 May 2011 14:23:13 +0200, a écrit :
On Tue, 2011-05-10 at 14:06 +0200, Samuel Thibault wrote:
...
Well objdump gave a lot of hits for mach_port_deallocate but
mach_port_deallocate_debug was not found.
Svante Signell, le Tue 10 May 2011 14:37:35 +0200, a écrit :
LOAD off0x1000 vaddr 0x0010 paddr 0x0010 align 2**12
filesz 0x001ab13c memsz 0x001ab13c flags r-x
LOAD off0x001ac140 vaddr 0x002ac140 paddr 0x002ac140 align 2**12
filesz 0x00010bcc memsz
23 matches
Mail list logo
