C function strtod() crashes with cgo on Windows, with gcc 64 bits

362 views
Skip to first unread message

nicolas...@gmail.com

unread,
Oct 14, 2014, 6:02:30 PM10/14/14
to golan...@googlegroups.com
My computer is Windows 7, 64 bits.

As I need cgo, I also installed tdm-gcc to have a 64 bits gcc.

C:\Users\rin01>go version
go version go1.3.3 windows/amd64

C:\Users\rin01>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/tdm-gcc-64/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.1/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-4.8.1/configure --build=x86_64-w64-mingw32 --enable-targets=all --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-libgomp --enable-lto --enable-graphite
--enable-cxx-flags=-DWINPTHREAD_STATIC --enable-libstdcxx-debug --enable-threads=posix --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libstdcxx-threads --enable-libstdcx
x-time --with-gnu-ld --disable-werror --disable-nls --disable-win32-registry --prefix=/mingw64tdm --with-local-prefix=/mingw64tdm --with-pkgversion=tdm64-2 --with-bugurl=http://tdm-gcc.tdragon.net/bug
s
Thread model: posix
gcc version 4.8.1 (tdm64-2)


This little Go program compiles with no problem.
  http://play.golang.org/p/wm5ADXs9KV

On Linux, it runs without problem.

But when I run it on Windows, it prints "sizeof double is: 8", and then crashes silently.
The crash occurs exactly at the C function "strtod".


Strangely enough, when I run this little C program, strtod works as expected.
  http://play.golang.org/p/ZvLIAYAa4u

Have someone the same problem ?


nicolas...@gmail.com

unread,
Oct 14, 2014, 7:21:31 PM10/14/14
to golan...@googlegroups.com, nicolas...@gmail.com
A similar problem exists with the C function "strtoll", when used with cgo on Windows.
the program compiles, but may crash at run time.

strtoll("9223372036854775807", &tailptr, 10);  doesn't crash

strtoll("9223372036854775808", &tailptr, 10);  crashes

strtol("9223372036854775808", &tailptr, 10);   doesn't crash

(note: 9223372036854775807 is int64 max value)

Konstantin Khomoutov

unread,
Oct 15, 2014, 6:18:30 AM10/15/14
to nicolas...@gmail.com, golan...@googlegroups.com
On Tue, 14 Oct 2014 15:02:30 -0700 (PDT)
nicolas...@gmail.com wrote:

> My computer is Windows 7, 64 bits.
> As I need cgo, I also installed tdm-gcc to have a 64 bits gcc.
[...]
> This little Go program compiles with no problem.
> http://play.golang.org/p/wm5ADXs9KV
>
> On Linux, it runs without problem.
>
> But when I run it on Windows, it prints "sizeof double is: 8", and
> then crashes silently.
> The crash occurs exactly at the C function "strtod".
How did you know this?
Did you try to run it under windbg or gdb?

nicolas...@gmail.com

unread,
Oct 15, 2014, 11:03:14 AM10/15/14
to golan...@googlegroups.com, nicolas...@gmail.com
I don't use gdb for debugging, I just insert "print" statements here and there, in Go code or C code, to track down the culprit line.

When I replace "strtod" with "strtold", the program works.
When it is "strtod", it crashes when run on Windows, but works on Linux.




Le mercredi 15 octobre 2014 00:02:30 UTC+2, nicolas...@gmail.com a écrit :

brainman

unread,
Oct 15, 2014, 9:34:50 PM10/15/14
to golan...@googlegroups.com, nicolas...@gmail.com
I don't know what the problem is, but I have created new issue for it https://code.google.com/p/go/issues/detail?id=8941.

Alex

stryker2k2

unread,
Feb 16, 2022, 9:19:41 AM2/16/22
to golang-nuts
Folks of golang-nuts,

It is now February of 2022 and it seems that "strtod" is still and issue. After hours of searching for a solution, I found this Google Group dated 8 years earlier (technically 7 1/2 years) and found my answer! So, although I am raising an old post from the grave, I feel that I must add in my findings for the next poor chap who sees this post in 8 years and also show my appreciation nearly a decade afterwards.

We have a very complex program that we compile for Windows 7/10 using the developers choice of either Ubuntu 18.04 ( gcc version 7.3-win32) and/or Ubuntu 20.04 (gcc version 9.3-win32). My developers using Ubuntu 18.04 (gcc 7.3) noticed that a portion of our program would crash when being accessed. I did some digging and this is what I saw...

`strtod` compiled on Ubuntu 18.04 (gcc 7.3) = CRASH
`strtod` compiled on Ubuntu 20.04 (gcc 9.3) = No Issue

That lead me to this post. 

We are now using `strtold` instead. `strtold` works on both version of Ubuntu/gcc.

Thank you all a ton for having this conversation 8+ years ago! You all rock!

Robert Engels

unread,
Feb 16, 2022, 9:29:39 AM2/16/22
to stryker2k2, golang-nuts
You might want to share a small reproducible test case - it is almost certainly an issue on your end. Most likely stack corruption creating invalid pointer/return addresses. When you return a double rather than a float you are changing the stack size and alignment. 

On Feb 16, 2022, at 8:19 AM, stryker2k2 <stryk...@gmail.com> wrote:

Folks of golang-nuts,
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/55152b22-0581-4780-82ce-e29f82310579n%40googlegroups.com.

Robert Engels

unread,
Feb 16, 2022, 9:33:04 AM2/16/22
to stryker2k2, golang-nuts
Apologies. I see the issue has a sample case attached. 

On Feb 16, 2022, at 8:27 AM, Robert Engels <ren...@ix.netcom.com> wrote:



Robert Engels

unread,
Feb 16, 2022, 9:51:54 AM2/16/22
to stryker2k2, golang-nuts
My guess is that you need to set the compiler options to ensure a double is 8 bytes to match Go. 

My point still applies - the stack is being corrupted due to a size mismatch in the parameters/return values. 

The fact that the original bug said it worked on Linux and crashed on windows and now it is crashing on two different versions of Linux is additional evidence. 

I think the exact compiler version and command line options are needed to diagnose. 

On Feb 16, 2022, at 8:27 AM, Robert Engels <ren...@ix.netcom.com> wrote:


Reply all
Reply to author
Forward
0 new messages