Zheng Da, le Wed 09 Jun 2010 01:22:48 -0400, a écrit :
> So which instruction triggers the trap? nop or movl?
movl, but it's not its ofwn fault.
My guess is that right after sti, an interrupt is triggered while nop is
being executed, gets handled after nop is executed, and we return to
movl, but
Hello,
On Tue, Jun 8, 2010 at 8:08 AM, Samuel Thibault wrote:
>> (null):~# addr2line -e /boot/gnumach-nodrv 0x13f163
>> /root/gnumach-build1/../gnumach/i386/i386at/interrupt.S:40
>> It's exactly where CPU should jump to. So it seems the stack is correct.
>
> Ok. So probably the protection is not
Hi,
On Tue, Jun 08, 2010 at 06:12:03PM +, Jose Luis Alarcon Sanchez
wrote:
> I have installed on my Debian GNU/Hurd system the package
> iceweasel-3.5.9-3 and all the dependencies it ask. The proccess was
> alright, but all the times i tried execute the binary the output was
>
> segmentatio
Jose Luis Alarcon Sanchez, le Tue 08 Jun 2010 18:12:03 +, a écrit :
> Why happen this?, Is GNU/Hurd, for any reason, uncapable of run this kind of
> "heavy desktop programs"?.
It should be able to. I've already tried gnumeric and iceape in the
past. That's probably just a bug that nobody has
Hello.
I have installed on my Debian GNU/Hurd system the package iceweasel-3.5.9-3 and
all the dependencies it ask. The proccess was alright, but all the times i
tried execute the binary the output was
segmentation fault (core dumped)
I'm using Hurd with 768 Mb. of RAM and the output of vmstat
Zheng Da, le Tue 08 Jun 2010 07:54:40 -0400, a écrit :
> On Mon, Jun 7, 2010 at 4:20 AM, Samuel Thibault
> wrote:
> > Zheng Da, le Mon 07 Jun 2010 01:40:26 -0400, a écrit :
> >> > examine 2f0094
> >> db> examine 0x1973e0
> >> 13f163
> >
> > Where does this point to in the source c
Hi,
On Mon, Jun 7, 2010 at 4:20 AM, Samuel Thibault wrote:
> Zheng Da, le Mon 07 Jun 2010 01:40:26 -0400, a écrit :
>> > examine 2f0094
>> db> examine 0x1973e0
>> 13f163
>
> Where does this point to in the source code?
(null):~# addr2line -e /boot/gnumach-nodrv 0x13f163
/root/gnum
