GHCi crashes with SIGFPE when using double-conversion package

[bos]

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)

[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.

[hgolden]

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.

[simonmar]

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.

[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.

[simonmar]

also reported as #5435, moving there