digitalmars.D - vibe.d - cannot allocate memory in static TLS block
- ddos (18/18) Aug 27 2015 when i import the vibe.d module my project it dies with the error
- Rikki Cattermole (5/23) Aug 27 2015 TLS = Thread Local Memory.
- ddos (3/5) Aug 27 2015 thx rikki, but sadly the newer version didn't solve my problems
- John Colvin (5/23) Aug 27 2015 Firstly, try with up-to-date vibe.d and zmqd.
- John Colvin (4/31) Aug 27 2015 P.S. this would be better asked in
- ddos (56/63) Aug 27 2015 made a thread before on the vibe forum too, see here
- ddos (2/2) Aug 27 2015 removing the import vibe.d is enough to make it work as a shared
- John Colvin (6/70) Aug 27 2015 I think your problem is that you need to initialise the D
- ddos (8/13) Aug 27 2015 i thought about that too, but that wasn't the case ( unless i
- John Colvin (7/20) Aug 27 2015 Unless I misunderstand what you're doing, the executable test
when i import the vibe.d module my project it dies with the error message "cannot allocate memory in static TLS block" compiled as dynamic library on debian x86 "name": "alice", "description": "A minimal D application.", "copyright": "Copyright © 2015, dom", "authors": ["dom"], "targetType": "dynamicLibrary", "dflags": ["-fPIC"], "dependencies": { "ddbc": "~>0.2.24", "zmqd": "~>1.0.0-alpha", "msgpack-rpc": "~>0.1.1", "vibe-d": "~>0.7.19" } import vibe.d; is enough to cause the error i don't really know what TLS is, but can i avoid it somehow? rgds, dominik
Aug 27 2015
On 27/08/15 9:06 PM, ddos wrote:when i import the vibe.d module my project it dies with the error message "cannot allocate memory in static TLS block" compiled as dynamic library on debian x86 "name": "alice", "description": "A minimal D application.", "copyright": "Copyright © 2015, dom", "authors": ["dom"], "targetType": "dynamicLibrary", "dflags": ["-fPIC"], "dependencies": { "ddbc": "~>0.2.24", "zmqd": "~>1.0.0-alpha", "msgpack-rpc": "~>0.1.1", "vibe-d": "~>0.7.19" } import vibe.d; is enough to cause the error i don't really know what TLS is, but can i avoid it somehow? rgds, dominikTLS = Thread Local Memory. Also 0.7.19 is quite an old version of vibe.d. Perhaps try 0.7.24 which is the last stable release (0.7.25 is in alpha according to git tags).
Aug 27 2015
On Thursday, 27 August 2015 at 09:10:59 UTC, Rikki Cattermole wrote:Perhaps try 0.7.24 which is the last stable release (0.7.25 is in alpha according to git tags).thx rikki, but sadly the newer version didn't solve my problems
Aug 27 2015
On Thursday, 27 August 2015 at 09:06:54 UTC, ddos wrote:when i import the vibe.d module my project it dies with the error message "cannot allocate memory in static TLS block" compiled as dynamic library on debian x86 "name": "alice", "description": "A minimal D application.", "copyright": "Copyright © 2015, dom", "authors": ["dom"], "targetType": "dynamicLibrary", "dflags": ["-fPIC"], "dependencies": { "ddbc": "~>0.2.24", "zmqd": "~>1.0.0-alpha", "msgpack-rpc": "~>0.1.1", "vibe-d": "~>0.7.19" } import vibe.d; is enough to cause the error i don't really know what TLS is, but can i avoid it somehow? rgds, dominikFirstly, try with up-to-date vibe.d and zmqd. What happens if you remove some of those dependencies? If you remove targetType dynamicLibrary? Is it just vibe.d on it's own that is causing the problem, or is it a combination?
Aug 27 2015
On Thursday, 27 August 2015 at 11:33:02 UTC, John Colvin wrote:On Thursday, 27 August 2015 at 09:06:54 UTC, ddos wrote:P.S. this would be better asked in http://forum.dlang.org/group/learn or http://forum.rejectedsoftware.comwhen i import the vibe.d module my project it dies with the error message "cannot allocate memory in static TLS block" compiled as dynamic library on debian x86 "name": "alice", "description": "A minimal D application.", "copyright": "Copyright © 2015, dom", "authors": ["dom"], "targetType": "dynamicLibrary", "dflags": ["-fPIC"], "dependencies": { "ddbc": "~>0.2.24", "zmqd": "~>1.0.0-alpha", "msgpack-rpc": "~>0.1.1", "vibe-d": "~>0.7.19" } import vibe.d; is enough to cause the error i don't really know what TLS is, but can i avoid it somehow? rgds, dominikFirstly, try with up-to-date vibe.d and zmqd. What happens if you remove some of those dependencies? If you remove targetType dynamicLibrary? Is it just vibe.d on it's own that is causing the problem, or is it a combination?
Aug 27 2015
On Thursday, 27 August 2015 at 11:34:36 UTC, John Colvin wrote:P.S. this would be better asked in http://forum.dlang.org/group/learn or http://forum.rejectedsoftware.commade a thread before on the vibe forum too, see here http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/26343/ On Thursday, 27 August 2015 at 11:34:36 UTC, John Colvin wrote:Firstly, try with up-to-date vibe.d and zmqd. What happens if you remove some of those dependencies? If you remove targetType dynamicLibrary? Is it just vibe.d on it's own that is causing the problem, or is it a combination?thx for the input, i've pulled out a smaller testing example from my codebase using only vibe as a dependency. if i compile this code as executable everything works as expected. Compiling it as a dynamicLibrary fails when the library is loaded. if this is of any help, that is the program the shared library is loaded into https://github.com/IceNinjaman/CoD4X17a_testing/ the used compile script: https://github.com/IceNinjaman/CoD4X17a_testing/blob/master/build_cod4x17a_elf_nopunkbuster.sh { "name": "vibefailtest", "description": "A minimal D application.", "copyright": "Copyright © 2015, vagrant", "authors": ["vagrant"], "targetType": "dynamicLibrary", "dependencies": { "vibe-d": "~>0.7.25-alpha.1", }, "versions": ["VibeCustomMain"] } import std.stdio; import vibe.d; struct version_t { int major; int minor; } align(1) struct pluginInfo_t{ // To be used in OnInfoRequest align(1): version_t handlerVersion; // Requested plugin handler version - mandatory field version_t pluginVersion; // Version of your plugin - optional char[64] fullName; // Full plugin name, short name is the filename without extension - optional char[128] shortDescription; // Describe in a few words what this plugin does - optional char[1024] longDescription; // Full description - optional } extern (C) void OnInfoRequest(pluginInfo_t *info) { info.handlerVersion = version_t(2, 302); info.pluginVersion = version_t(0, 1); } extern (C) int OnInit() { printf(">>>>>>>> init\n"); return 0; } void main(){ OnInit(); }
Aug 27 2015
removing the import vibe.d is enough to make it work as a shared library
Aug 27 2015
On Thursday, 27 August 2015 at 13:08:18 UTC, ddos wrote:On Thursday, 27 August 2015 at 11:34:36 UTC, John Colvin wrote:I think your problem is that you need to initialise the D runtime. Perhaps adding a call to inside OnInit will solve it for you. Also, remember to terminate the runtime when the plugin is unloaded.P.S. this would be better asked in http://forum.dlang.org/group/learn or http://forum.rejectedsoftware.commade a thread before on the vibe forum too, see here http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/26343/ On Thursday, 27 August 2015 at 11:34:36 UTC, John Colvin wrote:Firstly, try with up-to-date vibe.d and zmqd. What happens if you remove some of those dependencies? If you remove targetType dynamicLibrary? Is it just vibe.d on it's own that is causing the problem, or is it a combination?thx for the input, i've pulled out a smaller testing example from my codebase using only vibe as a dependency. if i compile this code as executable everything works as expected. Compiling it as a dynamicLibrary fails when the library is loaded. if this is of any help, that is the program the shared library is loaded into https://github.com/IceNinjaman/CoD4X17a_testing/ the used compile script: https://github.com/IceNinjaman/CoD4X17a_testing/blob/master/build_cod4x17a_elf_nopunkbuster.sh { "name": "vibefailtest", "description": "A minimal D application.", "copyright": "Copyright © 2015, vagrant", "authors": ["vagrant"], "targetType": "dynamicLibrary", "dependencies": { "vibe-d": "~>0.7.25-alpha.1", }, "versions": ["VibeCustomMain"] } import std.stdio; import vibe.d; struct version_t { int major; int minor; } align(1) struct pluginInfo_t{ // To be used in OnInfoRequest align(1): version_t handlerVersion; // Requested plugin handler version - mandatory field version_t pluginVersion; // Version of your plugin - optional char[64] fullName; // Full plugin name, short name is the filename without extension - optional char[128] shortDescription; // Describe in a few words what this plugin does - optional char[1024] longDescription; // Full description - optional } extern (C) void OnInfoRequest(pluginInfo_t *info) { info.handlerVersion = version_t(2, 302); info.pluginVersion = version_t(0, 1); } extern (C) int OnInit() { printf(">>>>>>>> init\n"); return 0; } void main(){ OnInit(); }
Aug 27 2015
On Thursday, 27 August 2015 at 15:16:25 UTC, John Colvin wrote:I think your problem is that you need to initialise the D runtime. Perhaps adding a call to inside OnInit will solve it for you. Also, remember to terminate the runtime when the plugin is unloaded.i thought about that too, but that wasn't the case ( unless i fucked something up ). nothing from my example gets executed, the crash happens i think when the library is loaded. just in case i've also added runtime.initialize also to the vibe main. also if the runtime.initialize would be missing that would mean my executable example should crash, but the executable test works just fine.
Aug 27 2015
On Thursday, 27 August 2015 at 15:40:20 UTC, ddos wrote:On Thursday, 27 August 2015 at 15:16:25 UTC, John Colvin wrote:Ok, yes, that isn't it then.I think your problem is that you need to initialise the D runtime. Perhaps adding a call to inside OnInit will solve it for you. Also, remember to terminate the runtime when the plugin is unloaded.i thought about that too, but that wasn't the case ( unless i fucked something up ). nothing from my example gets executed, the crash happens i think when the library is loaded.just in case i've also added runtime.initialize also to the vibe main. also if the runtime.initialize would be missing that would mean my executable example should crash, but the executable test works just fine.Unless I misunderstand what you're doing, the executable test would be initialising the runtime anyway, it's put in by the compiler when building an executable. The only other thing I can think of is: have you tried removing the main from your code, while still defining VibeCustomMain?
Aug 27 2015
i think i started to narrow down the error, and i think the actual error is not in vibe.d, or atleast no only there since import vibe.d causes the shared lib to crash my program, i investigated the vibe.d module. it consists of all the vibe submodule + some modules of phobos. so i started commenting out some of the modules to see which one are causing the error. first i removed all vibe modules and only left in the phobos modules ... crash again - wait what? import std.datetime; causes my library to crash -_- eeeek this is a different error now, but still importing std.datetime; in my test creates a segfault 0.o strange to be continued ... This program has crashed with signal: Segmentation fault The current Gameversion is: CoD4 X 1.7a linux-i386-custom_debug type 'e' build 3382 Aug 27 2015 File is ./cod4x17a_dedrun Hash is: 1c941e6f17d4b4bc3243e033707e1625e48ae9cfa232aeabc42f294ce5adaecc ---------- Crash Backtrace ---------- 2: .(Sys_DumpCrash+0xe7) [0x206a5c9] 1: .(Sys_SigHandler+0x3c) [0x206a70c] 0: linux-gate.so.1(__kernel_sigreturn+0) [0xf76e8d40] -- Registers --- edi 0xec0d41b8 esi 0x0 ebp 0xff88ce58 esp 0xff88ce30 eax 0xec0d9380 ebx 0xf770b000 ecx 0x8 edx 0x3960292072 eip 0x0 -------- Backtrace Completed -------- Received signal: Segmentation fault, exiting... Server received signal: Segmentation fault Shutting down server... ----- Server Shutdown ----- With the reason: Server received signal: Segmentation fault Terminating server... Sending heartbeat to cod4master.activision.com Sending heartbeat to cod4master.iceops.in Sending heartbeat to cod4master.activision.com Sending heartbeat to cod4master.iceops.in ==== ShutdownGame (1) ==== --------------------------- ./run.sh: line 1: 6629 Segmentation fault ./cod4x17a_dedrun +exec server.cfg
Aug 27 2015
-fpic was missing std.datetime didnt cause crash anymore after i added the fpic option import vibe.inet.url; import vibe.inet.urltransfer; import vibe.mail.smtp; import vibe.stream.counting; import vibe.stream.memory; import vibe.stream.operations; import vibe.stream.ssl; import vibe.stream.tls; import vibe.stream.zlib; //import vibe.templ.diet; //import vibe.templ.utils; import vibe.textfilter.html; import vibe.textfilter.markdown; import vibe.textfilter.urlencode; import vibe.utils.string; //import vibe.web.web; //import vibe.web.rest; from those modules, the commented out 4 cause the following error Error: Sys_LoadLibrary error: /home/vagrant/.callofduty4/plugin.failtest.tmp: cannot allocate memory in static TLS block Error: Failed to load the plugin /home/vagrant/.callofduty4/plugin.failtest.tmp!
Aug 27 2015
looks like too much global memory is allocated everything >1kb of global memory crashes with Error: Sys_LoadLibrary error: /home/vagrant/.callofduty4/plugin.failtest.tmp: cannot allocate memory in static TLS block Error: Failed to load the plugin /home/vagrant/.callofduty4/plugin.failtest.tmp! is there a way to increase the maximum storage space for global variables?
Aug 28 2015