On Mon, 2011-05-09 at 11:50 +0200, olafbuddenha...@gmx.net wrote:
> Hi,
>
> On Mon, May 09, 2011 at 08:30:23AM +0200, Svante Signell wrote:
..
> > I mean that changing strcpy to strdup everywhere is a major rewrite of
> > this old code.
>
> Who talked about changing it *everywhere*?! Your patch
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 mem
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
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
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 :
> > 2c10c0:
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 u
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,
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
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
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
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
>
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 q
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
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 compresse
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:
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
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
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
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" wrote:
Hi,
On Mon, May 09, 2011 at 08:30:23AM +0200, Svante Signell wrote:
> On Sun, 2011-05-08 at 18:56 +0200, olafbuddenha...@gmx.net wrote:
> > On Fri, Apr 15, 2011 at 03:55:49PM +0200, Svante Signell wrote:
> > > On Fri, 2011-04-15 at 01:08 +0200, Emilio Pozuelo Monfort wrote:
> > > > On 15/04/11 00:
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
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 se
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 a
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
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 run
25 matches
Mail list logo