What could cause this SEGV
Wed Jun 13 12:03:00 GMT 2018
On 06/13/2018 12:54 PM, Paul Smith wrote:
> On Wed, 2018-06-13 at 12:11 +0100, Andrew Haley wrote:
>>> Is there more I could do to track this down and understand it?
>>> Should I just proceed with the "working" _fastmath.so and call it
>>> good? It seems like there's some hole in my encapsulation that I
>>> can't see; I would prefer to find and patch it if possible...
>> It might be related to ordering. There very probably is something
>> really wrong, so I think it deserves more investigation. However,
>> I think you really have to debug it. gdb is your friend.
> I did make an effort to use GDB, but the code is compiled with a high
> level of optimization and stripped and there were no useful debug
OK, so you should fix that problem.
> Because of the nature of the object (python module, etc.) its build
> options are buried under several layers and not easy to modify. I
> will make more of an effort (recompile by hand etc.) and see where I
> If it is an ordering problem that implies to me that it's a bug in
> the _fastmath code, which is not properly accounting for ordering
> issues during static initialization, no?
It certainly could be that. Any writable static data in a shared
library is potentially problematic, especially if it is exported.
> Or is your concern that it could be an issue in the linker itself?
It's always been really difficult to make completely reproducible
builds, as you have seen. I suspect that you may have a problem with
multiply-defined symbols in libraries, in which case it's a matter of
luck which one gets found. It may also be a problem with copy relocs,
which are a truly evil hack, but let's not get ahead of ourselves.
Right now it's crucial not to make any assumptions about what is going
wrong. Keep a clear head and go where the evidence leads.
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the Gcc-help