Re: [elinks-dev] The Links/Links2/ELinks browsers are unusable on Debian GNU/Hurd
Hi,
On Thu, Dec 20, 2007 at 11:50:26PM +0100, Fabienne Ducroquet wrote:
> On Thu, Dec 20, 2007 at 06:29:51AM +0200, Kalle Olavi Niemitalo wrote:
> > I mean, the compiler might merely have decided to load the
> > address of free_itrm into a register at that point, or something
> > like that.
>
> But how could I see that?
Probably only by looking at the assembly code.
> > > As you can see, there is something wrong there,
> >
> > I don't see that.
>
> You are probably more experienced than me in that sort of thing, for
> me that seems at least very weird. :-)
The compiler shuffles instruction when doing strong optimizations, so
they often get executed in a different order then in the source code;
sometimes it's even impossible to tell where exactly some piece of code
came from. Thus gdb jumps around in the source code in a very confusing
manner.
It would really really help if you compile elinks with -O0 or -O1 before
running gdb on it...
> I tried rpctrace elinks but I don't know what to look for in the
> output...
Yeah, rpctrace output is quite hard to grasp because of the async nature
of things...
> There are lines such as:
>
> task2573->vm_deallocate (21331968 4096) = 0
> 88->io_select_request (2)task2573->mach_port_destroy (pn{ 25}) = 0
> reply(94:io_select_request)->io_select_reply (0 2);
> 72->io_write_request ("^[[1;1H" -1) = 0 6
> 52->io_select_request (5)task2573->mach_port_allocate (3) = 0 pn{ 29}
> task2573->mach_port_move_member (pn{ 25} pn{ 29}) = 0
> 86->io_select_request (5)task2573->mach_port_move_member (pn{ 27} pn{ 29}) = 0
> 88->io_select_request (6)task2573->mach_port_move_member (pn{ 28} pn{ 29}) = 0
> reply(96:io_select_request)->io_select_reply (0 2);
> task2573->mach_port_destroy (pn{ 25}) = 0
>
> What must I look here? the numbers between parenthesis after
> io_select_reply (in that case, they are always (0 1) or (0 2) or (0 0))?
Exactly. To find out what they mean, we have to look at the definition
of the io_select RPC in hurd/hurd/io.defs:
simpleroutine io_select_reply (
reply: reply_port_t;
RETURN_CODE_ARG;
select_result: int);
The reply port is hidden by rpctrace, so we only see two values. I have
no clue what the first one (RETURN_CODE_ARG) means. The second is the
select_result. To make sense of it, you probably need to look at the
select() implementation in the Hurd-specific glibc code.
It might be more useful actually to step through the select()
implementation rather then looking at rpctrace output. This way you can
see with what parameters it is called, what server it invokes, what
results it gets etc.
> > Also try putting the NULLs in ELinks
> > like I mentioned in the previous message.
>
> Something like the following patch? It seems to work, but perhaps it
> breaks something else.
Well, at least this way we know that this is indeed the problem. Now it
would be useful to find out whether the Hurd is doing anything wrong
here (POSIX should tell), and if so, try to find out why...
BTW, this issue is most certainly not Debian-specific. It would be
better discussed on bug-hurd@gnu.org -- better chance some clueful
developer will see it...
-antrik-
Reply to: