emacs-devel
[Top][All Lists]
Advanced

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

Re: bignum branch


From: Andy Moreton
Subject: Re: bignum branch
Date: Tue, 14 Aug 2018 00:13:54 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (windows-nt)

On Mon 13 Aug 2018, Eli Zaretskii wrote:

>> From: Andy Moreton <address@hidden>
>> Date: Sun, 12 Aug 2018 20:44:03 +0100
>> 
>> gdb: Target exception EXCEPTION_SINGLE_STEP at 0x40016c304
>> gdb: Target exception EXCEPTION_SINGLE_STEP at 0x46ace5dc0
>> 0x000000046ace5dc0 in ?? ()
>> (gdb)
>> Cannot find bounds of current function
>> (gdb) stepi
>> gdb: Target exception EXCEPTION_ACCESS_VIOLATION at 0x46ace5dc0
>> 
>> Thread 1 received signal SIGSEGV, Segmentation fault.
>> 0x000000046ace5dc0 in ?? ()
>
> Hmm... and what does this say?
>
>   (gdb) x/i 0x000000046ace5dc0

This is a different binary (master rebuilt from commit eb787d749f28),
but eh address are the same:

(gdb) s
__gmpz_popcount (__gmp_u=0x400c2e688 <dumped_data+5075752>) at 
C:/msys64/mingw64/include/gmp.h:1844
1844      if (__GMP_LIKELY (__gmp_usize > 0))
(gdb)
1845        __gmp_result =  mpn_popcount (__gmp_u->_mp_d, __gmp_usize);
(gdb)
0x000000046ace5dc0 in ?? ()
(gdb) x/i 0x000000046ace5dc0
=> 0x46ace5dc0: Cannot access memory at address 0x46ace5dc0
(gdb)
Undefined command: "".  Try "help".
(gdb) x/i 0x000000006ace5dc0
   0x6ace5dc0:  push   %rdi
(gdb)

>
> This address looks bogus to me.  Earlier, you reported:
>
>> Thread 1 received signal SIGSEGV, Segmentation fault.
>> 0x000000046ace5dc0 in ?? ()
>> (gdb) p mpn_popcount
>> $5 = {<text variable, no debug info>} 0x401e61484 <__imp___gmpn_popcount>
>> (gdb) x/xg mpn_popcount
>> 0x401e61484 <__imp___gmpn_popcount>:    0x000000006ace5dc0
>> (gdb) disas 0x000000006ace5dc0,+0x80
>
> I think your disassembly used the wrong address, it should have used
> this:
>
>   (gdb) disas 0x401e61484,+0x80
>
> I'd expect to see an indirect jump there.

Agreed.

> And notice how 0x000000006ace5dc0, the value at __imp___gmpn_popcount,
> and 0x000000046ace5dc0, where Emacs crashed, are the same value, up to
> the 0x0000000400000000 bit.  Hmm...

And notice that 0x0000000400000000 is the image base of emacs.exe:

..mingw64-x86_64/src> objdump -x emacs.exe | grep ^ImageBase
ImageBase               0000000400000000

This is almost as if it has assumed that __gmpn_popcount is a function
from the text of emacs.exe rather than from libgmp-10.dll.

> Feel free to change the program as you see fit.  I hoped that we will
> have a small enough test case to report to GCC and GMP developers.  If
> not, maybe it's worth to report to the GMP list anyway, they could
> have some ideas.

I have made some attempts to reproduce that bad behaviour, but so far
without success. I'll report back if I make more progress.

> It may also be a good idea to report the problem with gmp.h to the
> MSYS2 forum, they should fix the header anyway.  (Mingw.org already
> fixed theirs, as I reported related problems, not about Emacs, a few
> months ago.)

Looking at the MSYS2 on github, there was a pull request to fix the
broken header install problem for GMP, but the maintainers dropped it:
<https://github.com/Alexpux/MINGW-packages/pull/3941>

    AndyM





reply via email to

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