RejectedSoftware Forums

Sign up

executeShell bug?

Hello,

I have the following app.d:

import std.stdio, std.process;
void main() {
    "hello".writeln;
    executeShell(`uname -a`);
}

running:

$vibe-test>dub --vverbose

produces the following error:

dmd -of/tmp/dub/1732927460/vibe-test /tmp/dub/1732927460/temp.o -L-levent -L-levent_pthreads -L-lssl -L-lcrypto -g 
Running /tmp/dub/1732927460/vibe-test...
hello
Error: Program exited with code -11
Full exception: object.Exception@source/dub/generators/build.d(180): Program exited with code -11
5   dub                                 0x0000000103a9c08b pure @safe bool std.exception.enforce!(bool).enforce(bool, lazy const(char)[], immutable(char)[], ulong) + 107
6   dub                                 0x0000000103a8ba7b void dub.generators.build.BuildGenerator.generateProject(dub.generators.generator.GeneratorSettings) + 5595
7   dub                                 0x0000000103a6ac08 void dub.dub.Dub.generateProject(immutable(char)[], dub.generators.generator.GeneratorSettings) + 160
8   dub                                 0x0000000103a5c5b8 _Dmain + 6012
9   dub                                 0x0000000103b32361 extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).void runMain() + 33
10  dub                                 0x0000000103b31ec1 extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).void tryExec(scope void delegate()) + 45
11  dub                                 0x0000000103b323a8 extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).void runAll() + 56
12  dub                                 0x0000000103b31ec1 extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).void tryExec(scope void delegate()) + 45
13  dub                                 0x0000000103b31e7b _d_run_main + 447
14  dub                                 0x0000000103b31cb4 main + 20
15  dub                                 0x0000000103a5ae34 start + 52
16  ???                                 0x0000000000000002 0x0 + 2
Run 'dub help' for usage information.

Has anyone seen this before?
Im running on Mac OSX 10.8.4

Re: executeShell bug?

Yes, I've seen the same error on something totally unrelated.
It was a program that used httpclient incorrectly. No idea why or what is happening though.

On Sat, 29 Jun 2013 20:40:58 GMT, Joshua Niehus wrote:

Hello,

I have the following app.d:

import std.stdio, std.process;
void main() {
    "hello".writeln;
    executeShell(`uname -a`);
}

running:

$vibe-test>dub --vverbose

produces the following error:

dmd -of/tmp/dub/1732927460/vibe-test /tmp/dub/1732927460/temp.o -L-levent -L-levent_pthreads -L-lssl -L-lcrypto -g 
Running /tmp/dub/1732927460/vibe-test...
hello
Error: Program exited with code -11
Full exception: object.Exception@source/dub/generators/build.d(180): Program exited with code -11
5   dub                                 0x0000000103a9c08b pure @safe bool std.exception.enforce!(bool).enforce(bool, lazy const(char)[], immutable(char)[], ulong) + 107
6   dub                                 0x0000000103a8ba7b void dub.generators.build.BuildGenerator.generateProject(dub.generators.generator.GeneratorSettings) + 5595
7   dub                                 0x0000000103a6ac08 void dub.dub.Dub.generateProject(immutable(char)[], dub.generators.generator.GeneratorSettings) + 160
8   dub                                 0x0000000103a5c5b8 _Dmain + 6012
9   dub                                 0x0000000103b32361 extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).void runMain() + 33
10  dub                                 0x0000000103b31ec1 extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).void tryExec(scope void delegate()) + 45
11  dub                                 0x0000000103b323a8 extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).void runAll() + 56
12  dub                                 0x0000000103b31ec1 extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).void tryExec(scope void delegate()) + 45
13  dub                                 0x0000000103b31e7b _d_run_main + 447
14  dub                                 0x0000000103b31cb4 main + 20
15  dub                                 0x0000000103a5ae34 start + 52
16  ???                                 0x0000000000000002 0x0 + 2
Run 'dub help' for usage information.

Has anyone seen this before?
Im running on Mac OSX 10.8.4

Re: executeShell bug?

Am 29.06.2013 22:40, schrieb Joshua Niehus:

(...)

import std.stdio, std.process;
void main() {
    "hello".writeln;
    executeShell(`uname -a`);
}

running:

$vibe-test>dub --vverbose

produces the following error:

dmd -of/tmp/dub/1732927460/vibe-test /tmp/dub/1732927460/temp.o -L-levent -L-levent_pthreads -L-lssl -L-lcrypto -g 
Running /tmp/dub/1732927460/vibe-test...
hello
Error: Program exited with code -11
(...)


Have you tried running it separately (i.e. "dub build" + "./vibe-test")?
Maybe that gives a clue.

If it still crashes without an error message, running with GDB should
point to the source of error (if exit code -11 indicates a segmentation
fault here).

BTW, I tried the same program on 10.7.4 and it didn't crash.

Re: executeShell bug?

On Mon, 01 Jul 2013 08:13:25 +0200, Sönke Ludwig wrote:

Have you tried running it separately (i.e. "dub build" + "./vibe-test")?
Maybe that gives a clue.

yes and here is the output:

[09956E01:00000000 dbg] Create FreeListAlloc 8
[09956E01:00000000 dbg] Create FreeListAlloc 16
[09956E01:00000000 dbg] Create FreeListAlloc 32
[09956E01:00000000 dbg] Create FreeListAlloc 64
[09956E01:00000000 dbg] Create FreeListAlloc 128
[09956E01:00000000 dbg] Create FreeListAlloc 256
[09956E01:00000000 dbg] Create FreeListAlloc 512
[09956E01:00000000 dbg] Create FreeListAlloc 1024
[09956E01:00000000 dbg] Create FreeListAlloc 2048
[09956E01:00000000 dbg] Create FreeListAlloc 65540
[09956E01:00000000 dia] libevent version: 2.0.21-stable
[09956E01:00000000 dia] libevent is using kqueue for events.
[09956E01:00000000 dbg] Initializing OpenSSL...
[09956E01:00000000 dbg] ... done.
hello
[1]    7203 segmentation fault  ./vibe-test --vverbose


If it still crashes without an error message, running with GDB should
point to the source of error (if exit code -11 indicates a segmentation
fault here).

I've never used GDB before and didn't get far when running it against my app, will need to read up on it more (sorry)

BTW, I tried the same program on 10.7.4 and it didn't crash.

I noticed that when I run with rdmd:

$>dub --rdmd

It works

Re: executeShell bug?

On Mon, 01 Jul 2013 06:38:53 GMT, Joshua Niehus wrote:

I've never used GDB before and didn't get far when running it against my app, will need to read up on it more (sorry)

Followup: Here is the GDB output I got:

warning: Could not find object file "/Users/joshuaniehus/scripts/vibed/temp.o" - no debug information available for "source/app.d".

(gdb) run
Starting program: /Users/joshuaniehus/scripts/vibed/vibed 
Reading symbols for shared libraries +++................................ done
hello

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x000000010014a930 in D3std7process7environFNbNdNeZxPPa ()
(gdb) backtrace
#0  0x000000010014a930 in D3std7process7environFNbNdNeZxPPa ()
#1  0x000000010014afc3 in D3std7process9createEnvFxHAyaAyabZPxPa ()
#2  0x000000010014acfb in D3std7process16spawnProcessImplFNexAAaS3std5stdio4FileS3std5stdio4FileS3std5stdio4FilexHAyaAyaE3std7process6ConfigZC3std7process3Pid ()
#3  0x000000010014a9ed in D3std7process12spawnProcessFNexAAaS3std5stdio4FileS3std5stdio4FileS3std5stdio4FilexHAyaAyaE3std7process6ConfigZC3std7process3Pid ()
#4  0x0000000100000bcd in _Dmain ()
#5  0x0000000100122c65 in D2rt6dmain211_d_run_mainUiPPaPUAAaZiZi7runMainMFZv ()
#6  0x00000001001227b1 in D2rt6dmain211_d_run_mainUiPPaPUAAaZiZi7tryExecMFMDFZvZv ()
#7  0x0000000100122cb1 in D2rt6dmain211_d_run_mainUiPPaPUAAaZiZi6runAllMFZv ()
#8  0x00000001001227b1 in D2rt6dmain211_d_run_mainUiPPaPUAAaZiZi7tryExecMFMDFZvZv ()
#9  0x0000000100122765 in _d_run_main ()
#10 0x0000000100122594 in main ()

Re: executeShell bug?

On Mon, 01 Jul 2013 17:05:06 GMT, Joshua Niehus wrote:

On Mon, 01 Jul 2013 06:38:53 GMT, Joshua Niehus wrote:

I've never used GDB before and didn't get far when running it against my app, will need to read up on it more (sorry)

Followup: Here is the GDB output I got:

warning: Could not find object file "/Users/joshuaniehus/scripts/vibed/temp.o" - no debug information available for "source/app.d".

(gdb) run
Starting program: /Users/joshuaniehus/scripts/vibed/vibed 
Reading symbols for shared libraries +++................................ done
hello

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x000000010014a930 in D3std7process7environFNbNdNeZxPPa ()
(...)

Too bad it doesn't find the debug information. But it looks like either std.process.std_process_static_this wasn't called, or _NSGetEnviron returned a null pointer. But in any case, this should go to bugzilla. I would call "dub build -v" and execute the build command manually to see if it is still reproducible that way and then file a bug report there. But one interesting thing would be to see if it still crashes if the "vibe-d" dependency is removed from package.json (which I suppose is there, right?). Maybe it is some strange interaction that causes std.process to not get initialized.

Re: executeShell bug?

On Wed, 03 Jul 2013 14:37:33 GMT, Sönke Ludwig wrote:

Too bad it doesn't find the debug information. But it looks like either std.process.std_process_static_this wasn't called, or _NSGetEnviron returned a null pointer. But in any case, this should go to [bugzilla][1]. I would call "dub build -v" and execute the build command manually to see if it is still reproducible that way and then file a bug report there. But one interesting thing would be to see if it still crashes if the "vibe-d" dependency is removed from package.json (which I suppose is there, right?). Maybe it is some strange interaction that causes std.process to not get initialized.

[1]: http://d.puremagic.com/issues/

better late then never... also good to post here incase anyone else runs into this:

http://d.puremagic.com/issues/show_bug.cgi?id=11112