Go program loads a DLL compiled from Go code
What should I do Thank you.
go version 1.18
windows 10
Sometimes, after calling the operation, it can run normally for the first time. If it runs again, it will report an error, and then it will always report an error
Errors are reported as follows
fatal error: unexpected signal during runtime execution
[signal 0xc0000005 code=0x0 addr=0x0 pc=0x67b21ff5]
goroutine 1 [running, locked to thread]:
runtime.throw({0x67bdb25b?, 0xc0000240c0?})
C:/Program Files/Go/src/runtime/panic.go:1047 +0x65 fp=0xc00003b9c0 sp=0xc00003b990 pc=0x67b44085
runtime.sigpanic()
C:/Program Files/Go/src/runtime/signal_windows.go:249 +0x213 fp=0xc00003ba08 sp=0xc00003b9c0 pc=0x67b572f3
runtime.heapBitsSetType(0xb0b245?, 0x300000002?, 0x100c000034000?, 0x1943b4f9628?)
C:/Program Files/Go/src/runtime/mbitmap.go:921 +0x3d5 fp=0xc00003bb30 sp=0xc00003ba08 pc=0x67b21ff5
runtime.mallocgc(0x10, 0x67bc4ba0, 0x1)
C:/Program Files/Go/src/runtime/malloc.go:1050 +0x64d fp=0xc00003bba8 sp=0xc00003bb30 pc=0x67b1c58d
runtime.newobject(0x14?)
C:/Program Files/Go/src/runtime/malloc.go:1192 +0x27 fp=0xc00003bbd0 sp=0xc00003bba8 pc=0x67b1c927
os/exec.Command({0x67bd43ec, 0x8}, {0x0, 0x0, 0x0?})
C:/Program Files/Go/src/os/exec/exec.go:274 +0x38 fp=0xc00003bc28 sp=0xc00003bbd0 pc=0x67b9f6d8
main.main()
D:/code/test_dll/main.go:68 +0x2c fp=0xc00003bc60 sp=0xc00003bc28 pc=0x67ba336c
main.RunHacking8(...)
D:/code/test_dll/main.go:60
_cgoexp_b07154bc348b_RunHacking8(0x0?)
_cgo_gotypes.go:39 +0x27 fp=0xc00003bc70 sp=0xc00003bc60 pc=0x67ba33c7
runtime.cgocallbackg1(0x67ba33a0, 0xc000026000?, 0x0)
C:/Program Files/Go/src/runtime/cgocall.go:316 +0x2c2 fp=0xc00003bd40 sp=0xc00003bc70 pc=0x67b13f82
runtime.cgocallbackg(0xc000034000?, 0x300000002?, 0xc000034000?)
C:/Program Files/Go/src/runtime/cgocall.go:235 +0x105 fp=0xc00003bdd0 sp=0xc00003bd40 pc=0x67b13bc5
runtime.cgocallbackg(0x67ba33a0, 0x6b639ffadf, 0x0)
<autogenerated>:1 +0x36 fp=0xc00003bdf8 sp=0xc00003bdd0 pc=0x67b702d6
runtime: g 1: unexpected return pc for runtime.cgocallback called from 0xb542a0
stack: frame={sp:0xc00003bdf8, fp:0xc00003be20} stack=[0xc00003a000,0xc00003c000)
runtime.cgocallback(0xb02a8b, 0xb57e20, 0xbd4940)
C:/Program Files/Go/src/runtime/asm_amd64.s:994 +0xd7 fp=0xc00003be20 sp=0xc00003bdf8 pc=0x67b6e097
I found the problem because my dll calls another dll which cannot be called again
Related
I'm using a third part DLL that I've used successfully for ages. Now the linker links the dll lib without complaint but the exe doesn't load the dll.
I recently upgraded from the 32 bit to 64 bit cygwin.
I'm doing a mingw cross compile to 32 bits.
I'm trying to use the FTDI USB interface FTD2XX dll.
I have the version 2.04.06 FTD2XX lib, .h, and dll.
I had been using that dll successfully for ages but with older versions of cygwin and mingw.
Recently upgraded to cygwin64.
The app appears to link with the FTD2XX.lib without complaint.
But when I run the app it doesn't seem to look for or load the FTD2XX.dll.
The app runs but crashes as soon as it tries to call something in FTD2XX dll.
I created a simple hello_dll.dll for side by side test. That works.
The app.c does calls on both hello_dll.dll and ftd2xx.dll.
Is starts without complain, successfully calls function in hello_dll, and then it crashes on a call to ft2xx.dll.
(I renamed the lib to ftd2xx_2.04.06 to distinguish them from other versions I have. Newer versions don't work any better.)
Link with -verbose gives:
i686-w64-mingw32-gcc -Wall -m32 -g -O2 -c -I . -o app.o app.c
i686-w64-mingw32-gcc -Wall -m32 -o app.exe app.o -Wl,-verbose -L. -lhello_dll -lftd2xx_2.04.06
GNU ld (GNU Binutils) 2.34.50.20200227
Supported emulations:
i386pe
using internal linker script:
<snip>
/usr/lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld: mode i386pe
attempt to open /usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/crt2.o succeeded
/usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/crt2.o
attempt to open /usr/lib/gcc/i686-w64-mingw32/9.2.0/crtbegin.o succeeded
/usr/lib/gcc/i686-w64-mingw32/9.2.0/crtbegin.o
attempt to open app.o succeeded
app.o
<snip>
attempt to open ./hello_dll.lib succeeded
./hello_dll.lib
(./hello_dll.lib)d000001.o
(./hello_dll.lib)d000000.o
(./hello_dll.lib)d000002.o
<snip>
attempt to open ./ftd2xx_2.04.06.lib succeeded
./ftd2xx_2.04.06.lib
(./ftd2xx_2.04.06.lib)FTD2XX.dll
(./ftd2xx_2.04.06.lib)FTD2XX.dll
(./ftd2xx_2.04.06.lib)FTD2XX.dll
(./ftd2xx_2.04.06.lib)FTD2XX.dll
::::::::::::::::::::::::::::
I obtained a 32 bit compatible version of gdb. When I run gdb:
GNU gdb (GDB) 7.7.50.20140303-cvs
<snip>
This GDB was configured as "i686-pc-mingw32".
<snip>
(gdb) break main
(gdb) Breakpoint 1 at 0x40267b: file app.c, line 28.
(gdb) run
(gdb) Starting program: C:\_d\aaa\pd\src\dll\pathological\app.exe
[New Thread 1428.0x2528]
Breakpoint 1, main (argc=1, argv=0x9b2f70) at app.c:28
28 dostuff();
(gdb) info share
(gdb) From To Syms Read Shared Object Library
0x774e0000 0x77644ccc Yes (*) C:\Windows\SysWOW64\ntdll.dll
0x753d0000 0x754cadec Yes (*) C:\Windows\syswow64\kernel32.dll
0x75ea1000 0x75ee6a3a Yes (*) C:\Windows\syswow64\KernelBase.dll
0x64081000 0x6408a1d8 Yes C:\_d\aaa\pd\src\dll\pathological\hello_dll.dll
0x75041000 0x750eb2c4 Yes (*) C:\Windows\syswow64\msvcrt.dll
(*): Shared library is missing debugging information.
(gdb) A debugging session is active.
(gdb) c
Continuing.
Hello dll. <--- The function in hello_dll.dll prints this.
Program received signal SIGSEGV, Segmentation fault.
0x8000004c in ?? () <----- call to FT_GetLibraryVersion()
(gdb) bt
#0 0x8000004c in ?? ()
#1 0x0040158e in dostuff () at app.c:49
#2 0x00402680 in main (argc=1, argv=0x8e2f70) at app.c:28
(gdb)
It links with the lib without complaint but when I run the exe it (silently) doesn't load the dll.
Anybody have any ideas? Is there some linker control that I am missing? Are there other diagnostic or debug tools to dig into this further?
:::::::::::::::::::::::
edit 7/11/20
I'll post some code. (If I know how. I'm new here.)
It should be shown in the "info share", but it isn't, as you can see above.
I'm suspecting name decoration. Objdump -x of the .exe shows an entry for FTD2XX.dll in the Import Tables. But it doesn't show any vma or bound name under it. I suspect that at program load the loader sees no vma/name and decides it doesn't really need to load the dll.
There is an import table in .idata at 0x406000
<snip>
The Import Tables (interpreted .idata section contents)
vma: Hint Time Forward DLL First
Table Stamp Chain Name Thunk
00006000 0000607c 00000000 00000000 00006218 0000614c
DLL Name: FTD2XX.dll
vma: Hint/Ord Member-Name Bound-To
<----- empty?
00006014 00006080 00000000 00000000 000064f8 00006150
DLL Name: hello_dll.dll
vma: Hint/Ord Member-Name Bound-To
6224 1 hello_dll
00006028 00006088 00000000 00000000 00006554 00006158
DLL Name: KERNEL32.dll
vma: Hint/Ord Member-Name Bound-To
6230 277 DeleteCriticalSection
6248 310 EnterCriticalSection
<snip>
:::::::::::::::::::::::::::::::::::::::::::::
edit 2, 7/11/20
This is the program that calls functions in the DLLs.
/* app.c
Demonstrates using the function imported from the DLL.
*/
// 200708 pathological case. Based on the simple hello_dll.
//#include <stdlib.h>
// for sleep
#include <unistd.h>
#include <stdio.h>
// for dword
#include <windef.h>
// for lpoverlapped
#include <minwinbase.h>
#include "hello_dll.h"
// My legacy app, and really all others too, use 2.04.06.h
#include "ftd2xx_2.04.06.h"
//#include "ftd2xx_2.02.04.h"
///////////////////////////
void dostuff( void );
void call_ft_listdevices( void );
///////////////////////////
int main(int argc, char** argv)
{
FT_STATUS status;
DWORD libver;
//dostuff();
printf( "Calling hello_dll():\n" );
fflush( stdout );
hello_dll();
fflush( stdout );
printf( "Back from hello_dll()\n" );
fflush( stdout );
sleep( 1 );
printf( "Calling FT_GetLibraryVersion().\n" );
fflush( stdout );
status = FT_GetLibraryVersion( &libver );
if( status == FT_OK ){
printf( "FTD2XX library version 0x%lx\n", libver );
fflush( stdout );
}
else{
printf( "Error reading FTD2XX library version.\n" );
fflush( stdout );
}
// 200710 Adding call to different ft function did
// not result in entries in the import table.
//call_ft_listdevices( );
return 0;
}
I don't think there is a need to include the code for my hello_dll. It works.
I have three versions of the FTD2XX. I'm pretty careful about tracking versions. Plus, when one is beating one's head against the wall, double checking the versions appeals early on as a way to end the pain.
I found a surprise copy of FTD2XX.dll. It's in c:/Windows/SysWOW64. It is the oldest of the three versions I have. Versions of my app that were compiled before this problem started run correctly using that dll in that place.
Solved.
There's a bug in the 2.34.50.20200227 i686-w64-mingw32-ld.exe. It won't work with ftd2xx.lib, regardless of ftd2xx version as far as I can tell.
2.25.51.20150320 and 2.29.1.20171006 work with ftd2xx.lib. I've reverted back to 2.29 mingw64-i686-binutils. I'm running again.
I am trying to compile Opensips on Clion as I want to debug and step through the code. I have tried adding environment variables through following lines in CMakeLists.txt:
set(CMAKE_C_FLAGS "-funroll-loops -Wcast-align -Wall -minline-all-stringops -falign-loops -ftree-vectorize -mtune=nocona -Wold-style-definition -Wmissing-field-initializers -Wredundant-decls" )
add_definitions(-DPKG_MALLOC -DSHM_MMAP -DUSE_MCAST -DDISABLE_NAGLE -DSTATISTICS -DHAVE_RESOLV_RES -DF_MALLOC -DF_MALLOC_OPTIMIZATIONS -DNAME='"opensips"' -DVERSION='"2.4.2"' -DARCH='"x86_64"' -DOS='"linux"' -DCOMPILER='"gcc 4.8.5"' -D__CPU_x86_64 -D__OS_linux -D__SMP_yes -DCFG_DIR='"/usr/local//etc/opensips/"' -DVERSIONTYPE='"git"' -DTHISREVISION='"c035556"' -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT)
===========================================================
I get following errors and I am not sure which package is missing:
-- Build files have been written to: /root/opensips-2.4/cmake-build-debug
[ 0%] Building C object CMakeFiles/opensips_2_4.dir/cachedb/test/test_backends.c.o
[ 0%] Building C object CMakeFiles/opensips_2_4.dir/cachedb/example/example_cachedb.c.o
/root/opensips-2.4/cachedb/test/test_backends.c:21:17: fatal error: tap.h: No such file or directory
include
^
compilation terminated.
gmake[2]: * [CMakeFiles/opensips_2_4.dir/cachedb/test/test_backends.c.o] Error 1
gmake[2]: * Waiting for unfinished jobs....
/root/opensips-2.4/cachedb/example/example_cachedb.c:75:2: warning: character constant too long for its type [enabled by default]
MODULE_VERSION,
^
/root/opensips-2.4/cachedb/example/example_cachedb.c:75:2: warning: initialization makes pointer from integer without a cast [enabled by default]
/root/opensips-2.4/cachedb/example/example_cachedb.c:75:2: warning: (near initialization for ‘exports.version’) [enabled by default]
In file included from /root/opensips-2.4/cachedb/example/../../sr_module.h:52:0,
from /root/opensips-2.4/cachedb/example/example_cachedb.c:32:
/root/opensips-2.4/cachedb/example/../../version.h:26:37: error: expected ‘}’ before string constant
define OPENSIPS_FULL_VERSION NAME " " VERSION " (" ARCH "/" OS ")"
^
/root/opensips-2.4/cachedb/example/../../sr_module.h:102:2: note: in expansion of macro ‘OPENSIPS_FULL_VERSION’
OPENSIPS_FULL_VERSION,
^
/root/opensips-2.4/cachedb/example/example_cachedb.c:75:2: note: in expansion of macro ‘MODULE_VERSION’
MODULE_VERSION,
^
/root/opensips-2.4/cachedb/example/example_cachedb.c:75:2: warning: character constant too long for its type [enabled by default]
/root/opensips-2.4/cachedb/example/example_cachedb.c:75:2: warning: character constant too long for its type [enabled by default]
/root/opensips-2.4/cachedb/example/example_cachedb.c:75:2: warning: character constant too long for its type [enabled by default]
/root/opensips-2.4/cachedb/example/example_cachedb.c:89:1: warning: missing initializer for field ‘compile_flags’ of ‘struct module_exports’ [-Wmissing-field-initializers]
};
^
In file included from /root/opensips-2.4/cachedb/example/example_cachedb.c:32:0:
/root/opensips-2.4/cachedb/example/../../sr_module.h:175:8: note: ‘compile_flags’ declared here
char compile_flags; /!< compile flags used on the module /
^
/root/opensips-2.4/cachedb/example/example_cachedb.c:95:12: warning: ‘mod_init’ defined but not used [-Wunused-function]
static int mod_init(void)
^
/root/opensips-2.4/cachedb/example/example_cachedb.c:137:12: warning: ‘child_init’ defined but not used [-Wunused-function]
static int child_init(int rank)
^
/root/opensips-2.4/cachedb/example/example_cachedb.c:154:13: warning: ‘destroy’ defined but not used [-Wunused-function]
static void destroy(void)
^
/root/opensips-2.4/cachedb/example/example_cachedb.c:59:21: warning: ‘cmds’ defined but not used [-Wunused-variable]
static cmd_export_t cmds[]=
^
/root/opensips-2.4/cachedb/example/example_cachedb.c:65:23: warning: ‘params’ defined but not used [-Wunused-variable]
static param_export_t params[]={
^
gmake[2]: [CMakeFiles/opensips_2_4.dir/cachedb/example/example_cachedb.c.o] Error 1
gmake[1]: * [CMakeFiles/opensips_2_4.dir/all] Error 2
gmake: *** [all] Error 2
The tap.h error is due to the fact that you have enabled unit-testing support in your build, via the -DUNIT_TESTS flag in Makefile.conf. If you still want to go down this route and run the cachedb-related unit tests for MongoDB/Cassandra:
download libtap, from here
make and sudo make install
I am suddenly receiving this error message when compiling my app:
elm make src/App.elm --output ../assets/javascripts/elm/App.js
elm: not enough bytes
CallStack (from HasCallStack):
error, called at libraries/binary/src/Data/Binary.hs:212:21 in binary-0.8.5.1:Data.Binary
make: *** [App.js] Error 1
Compiler bug?
Edit: The workaround is to delete elm-stuff. Then it will compile once, and have the same bug on the next attempt.
If I compile and run
! main.f90
print*, 1/0
end program
with ifort then I get a division by zero error with an exit status of 2 (echo $?), as expected. However, If I compile using ifort -coarray=shared then I still get the error but now the exit status is 0. The problem is that CTest is unable to catch the error. This is my CMakeLists.txt:
cmake_minimum_required(VERSION 2.8)
project(testing Fortran)
enable_testing()
add_executable(main EXCLUDE_FROM_ALL main.f90)
add_test(main main)
add_custom_target(check COMMAND ctest DEPENDS main)
If I run make check then the output is
100% tests passed, 0 tests failed out of 1
even though the test actually failed. If I remove -coarray=shared or use gfortran then I get the correct output
0% tests passed, 1 tests failed out of 1
How can I make CTest report that the test failed? Am I doing something wrong or is this a compiler bug?
I'm testing with ifort 14.0.1 with the example code
program test
implicit none
print *, 1/0
end program
I can't quite replicate your initial return value of 3. In my testing the result of echo $? is 71, which correlates to the message thrown from the runtime error (note: gfortran won't even compile the example):
forrtl: severe (71): integer divide by zero
I am however replicating your return code of 0 from the coarray version. What is happening here is a bit more complicated, as ifort implements coarrays through MPI calls and for -coarray=shared basically wraps your program in a wrapper so you do not have to call mpirun, mpiexec or have to run intel's mpd to handle MPI communications. It is clear that the coarray images (MPI ranks) are all returning with error code 3:
application called MPI_Abort(comm=0x84000000, 3) - process 4
and
exit status of rank 1: return code 3
is emitted by each MPI rank, but the executable itself always returns with exit code 0. Whether this is the intended behavior or a bug is not clear to me, but it seems likely that the wrapper code to launch the MPI processes doesn't look at the MPI return codes from each rank. As pointed out in the comments, how would we expect different return values from different mpi ranks to be handled? It doesn't seem you are doing anything wrong.
Contrast this with a normal MPI example:
program mpitest
use mpi
implicit none
integer :: rank, msize, merror, mstatus(MPI_STATUS_SIZE)
call MPI_INIT(merror)
call MPI_COMM_SIZE(MPI_COMM_WORLD, msize, merror)
call MPI_COMM_RANK(MPI_COMM_WORLD, rank, merror)
print *, 1/0
call MPI_FINALIZE(merror)
end program
compiled with
mpiifort -o testmpi testmpi.f90
and run as (with mpd running):
mpirun -np 4 ./testmpi
This produced a severe runtime error 71 for integer divide by zero for each rank as before, but the error code is propagated back to the shell:
$ echo $?
71
I'm using a MBP OSX(10.9) and is new to CLucene and I'm having problem installing it. Despite following the installation guide closely, I still hit these errors while making the file
[ 0%] Building CXX object src/shared/CMakeFiles/clucene-shared.dir/CLucene/SharedHeader.o
In file included from /Users/youhock/Downloads/clucene-core-2.3.3.4/src/shared/CLucene/SharedHeader.cpp:8:
In file included from /Users/youhock/Downloads/clucene-core-2.3.3.4/src/shared/CLucene/_SharedHeader.h:13:
In file included from /Users/youhock/Downloads/clucene-core-2.3.3.4/src/shared/CLucene/SharedHeader.h:201:
In file included from /Users/youhock/Downloads/clucene-core-2.3.3.4/src/core/CLucene/debug/lucenebase.h:10:
/Users/youhock/Downloads/clucene-core-2.3.3.4/src/shared/CLucene/LuceneThreads.h:56:19: error:
unknown type name 'pthread_t'
static _LUCENE_THREADID_TYPE _GetCurrentThreadId();
^
/Users/youhock/Downloads/clucene-core-2.3.3.4/src/shared/CLucene/LuceneThreads.h:40:41: note:
expanded from macro '_LUCENE_THREADID_TYPE'
#define _LUCENE_THREADID_TYPE pthread_t
^
/Users/youhock/Downloads/clucene-core-2.3.3.4/src/shared/CLucene/LuceneThreads.h:57:18: error:
unknown type name 'pthread_t'
static _LUCENE_THREADID_TYPE CreateThread(lucene...
^
/Users/youhock/Downloads/clucene-core-2.3.3.4/src/shared/CLucene/LuceneThreads.h:40:41: note:
expanded from macro '_LUCENE_THREADID_TYPE'
#define _LUCENE_THREADID_TYPE pthread_t
^
/Users/youhock/Downloads/clucene-core-2.3.3.4/src/shared/CLucene/LuceneThreads.h:58:34: error:
unknown type name 'pthread_t'
static void JoinThread(_LUCENE_THREADID_TYPE id);
^
/Users/youhock/Downloads/clucene-core-2.3.3.4/src/shared/CLucene/LuceneThreads.h:40:41: note:
expanded from macro '_LUCENE_THREADID_TYPE'
#define _LUCENE_THREADID_TYPE pthread_t
^
3 errors generated.
make[2]: *** [src/shared/CMakeFiles/clucene-shared.dir/CLucene/SharedHeader.o] Error 1
make[1]: *** [src/shared/CMakeFiles/clucene-shared.dir/all] Error 2
make: *** [all] Error 2
Appreciate if anyone could help me with this? Thanks in advance
Have a look at my other answer.
Bascially you have to patch
src/shared/CLucene/LuceneThreads.h
src/shared/CLucene/config/repl_tchar.h
The other post contains the links as well.