Opened 6 years ago

Closed 6 years ago

#5386 closed bug (duplicate)

GHCi crashes with SIGFPE when using double-conversion package

Reported by: bos Owned by:
Priority: high Milestone: 7.4.1
Component: GHCi Version: 7.0.4
Keywords: Cc: howard_b_golden@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: GHCi crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

This is 100% reproducible. Install the double-conversion package:

cabal install double-conversion

And now kill GHCi:

Prelude> :m +Data.Double.Conversion.ByteString Data.ByteString
Prelude> toShortest 3
"Floating point exception (core dumped)

Change History (5)

comment:1 Changed 6 years ago by bos

I've narrowed the source of the bug down.

The crash occurs on line 153 of cached-powers.cc in the double-conversion source, where a divide by zero occurs because kDecimalExponentDistance is zero.

Now it's clear from the definition of that variable that it should not be zero; its value should be 8.

However, on inspecting the symbols in the compiled source file, I see that the symbol for kDecimalExponentDistance is actually in the BSS section of the object file. It looks like its value is supposed to be computed at startup time by an initializer, which I assume is the first symbol in the list below:

00000000 t _GLOBAL__sub_I__ZN17double_conversion16PowersOfTenCache24kDecimalExponentDistanceE
00000000 B double_conversion::PowersOfTenCache::kMaxDecimalExponent
00000004 B double_conversion::PowersOfTenCache::kMinDecimalExponent
00000008 B double_conversion::PowersOfTenCache::kDecimalExponentDistance

This is all a roundabout way of saying that the crash seems to be due to GHCi not calling initializers.

comment:2 in reply to:  1 Changed 6 years ago by hgolden

Cc: howard_b_golden@… added

Replying to bos:

This is all a roundabout way of saying that the crash seems to be due to GHCi not calling initializers.

bos, does this work properly when compiled by ghc with a suitable main? I'm trying to figure out whether ghci should call the initializers or if that task belongs to some other part of the ABI. When a C++ function has a C interface, it seems (naively) to me that it should handle its own initialization since the caller shouldn't need to know that the C interface is wrapping a C++ function. I guess I better study how this is supposed to work.

comment:3 Changed 6 years ago by simonmar

Milestone: 7.4.1
Priority: normalhigh

It's true, GHCi doesn't call constructors when it loads a .o or a .a file. However, shared libraries are loaded by the system linker and constructors will be run as normal. So one workaround is to put your C++ code into a shared library (but then you can't just use c-sources in Cabal of course).

How difficult it would be to implement this I don't know, maybe it wouldn't be too hard. We should at least look into it.

comment:4 in reply to:  3 Changed 6 years ago by hgolden

Replying to simonmar:

How difficult it would be to implement this I don't know, maybe it wouldn't be too hard. We should at least look into it.

Perhaps this will help: The gory details are explained here (http://www.akkadia.org/drepper/dsohowto.pdf), especially section 1.5.6.

comment:5 Changed 6 years ago by simonmar

Resolution: duplicate
Status: newclosed

also reported as #5435, moving there

Note: See TracTickets for help on using tickets.