bug-hurd
[Top][All Lists]
Advanced

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

Re: gnumach FTBFS: Was Re: Race condition in Mach/Hurd?


From: Samuel Thibault
Subject: Re: gnumach FTBFS: Was Re: Race condition in Mach/Hurd?
Date: Fri, 13 May 2011 21:12:43 +0200
User-agent: Mutt/1.5.12-2006-07-14

Svante Signell, le Thu 12 May 2011 17:40:47 +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, 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 kernel start the in-kernel debugger in that
> > > > case. Simply set the mach_port_deallocate_debug variable to 1,
> > > 
> > > Where to set this variable? In the source code of gnumach, recompile,
> > > install
> > 
> > Yes.
> 
> Looks like gnumach-1.3.99.dfsg.git20110305 does not build from source
> any longer:
> make[3]: Entering directory
> `/home/srs/DEBs/gnumach/gnumach-1.3.99.dfsg.git20110305/build'
> if test -s gnumach-undef-bad; \
>         then cat gnumach-undef-bad; exit 2; else true; fi
> .L430

This looks extremely odd.  Labels like .L430 are not supposed to be
external symbols, but file-local symbols.  Are you building from a
hurd-i386 system or (linux-)i386 system?

Samuel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]