Hi -
My new and improved rpctrace is generating kernel panics when run on
ext2fs. This happens when rpctrace calls gsync_wait, with ext2fs as the
'task' argument.
Could you guys look at gnumach's kern/gsync.c, at line 212? It looks to me
like that code tacitly assumes that the 'addr' it's acces
"Brent W. Baccala" writes:
> My solution is to signal the condition variable right before the call to
> mach_msg, but this creates a race condition where messages can get
> reordered.
>
> As you know, I never liked this blocking behavior of mach_msg, but I just
> can't see any way around it now.
Hi -
I'm using my newly enhanced rpctrace to hunt down a few bugs.
Here's a minor one in glibc that shows up like this on "rpctrace /bin/true":
task337(pid1240)->mach_port_deallocate (pn{ 0}) = 0xf ((os/kern) invalid
name)
The trick is to get rpctrace to halt the process when it encounters
som
On Sat, Oct 29, 2016 at 1:48 PM, Brent W. Baccala
wrote:
> Yes, patch7 without patch8 can reorder messages as they're being resent,
> but patch8 uses the mutex introduced in patch7, so the ordering can't be
> reversed.
>
> They could be combined into a single patch. Do you want me to prepare a
>
On Sat, Oct 29, 2016 at 1:40 PM, Brent W. Baccala
wrote:
> On Oct 29, 2016 2:53 AM, "Samuel Thibault"
> wrote:
> >
> > Hello,
> >
> > > #define easprintf(args...)assert(asprintf (args) != -1)
> >
> > That will be removed when building with -DNDEBUG, not a good thing :)
>
> An excellent p
Hello,
Brent W. Baccala, on Sat 29 Oct 2016 13:40:24 -1000, wrote:
> > Also, I don't see copyright assignment in the FSF records, did you start
> > making one?
>
> No, I haven't. What should I use, request-assign.program, sent to
> fsf-records?
request-assign.future, rather, sent to ass...@gnu
