Hello I have very simple line with exec-command:

execl("/bin/bash".toStringz(), "/bin/bash".toStringz(), "-c".toStringz(), command.toStringz(), null);

And on this line on toStringz my program sometimes hangs.
backtrace:

(gdb) bt
#0  0x00007f3acd535c6d in nanosleep () at ../sysdeps/unix/syscall-template.S:84
#1  0x000000000066f57e in core.thread.Thread.sleep(core.time.Duration) ()
#2  0x00000000006b2824 in core.internal.spinlock.SpinLock.yield(ulong) shared
    ()
#3  0x00000000006b27c0 in core.internal.spinlock.SpinLock.lock() shared ()
#4  0x00000000006a7244 in gc.gc.GC.runLocked!(gc.gc.GC.mallocNoSync(ulong, uint, ref ulong, const(TypeInfo)), gc.gc.mallocTime, gc.gc.numMallocs, ulong, uint, ulong, const(TypeInfo)).runLocked(ref ulong, ref uint, ref ulong, ref const(TypeInfo)) ()
#5  0x00000000006a0bc6 in gc.gc.GC.malloc(ulong, uint, ulong*, const(TypeInfo))
    ()
#6  0x00000000006721d3 in gc_qalloc ()
#7  0x00000000006a99a1 in rt.lifetime.__arrayAlloc(ulong, const(TypeInfo), const(TypeInfo)) ()
#8  0x000000000067523a in _d_newarrayU ()
#9  0x0000000000675324 in _d_newarrayiT ()
#10 0x000000000068fde6 in std.string.toStringz(const(char)[]) ()
#11 0x000000000068fe79 in std.string.toStringz(const(immutable(char)[])) ()
#12 0x0000000000592dc9 in unde.command_line.run.fork_command(unde.global_state.CMDGlobalState, immutable(char)[], immutable(char)[], std.concurrency.Tid) (
    tid=..., command=..., cwd=..., cgs=0x7f3abcdffb80)
    at source/unde/command_line/run.d:2002

What is it? For what it waits?

On Tuesday, 27 December 2016 at 17:27:14 UTC, unDEFER wrote:
> Hello I have very simple line with exec-command:
>
> execl("/bin/bash".toStringz(), "/bin/bash".toStringz(), "-c".toStringz(), command.toStringz(), null);
>
> [...]

The string is allocated on the gc-ed heap.
And since it's an R value it might get destroyed before execl is finished.
Assign the result of toStringz to a char* variable and use that in the call.

On Tuesday, 27 December 2016 at 17:50:14 UTC, Stefan Koch wrote:
> The string is allocated on the gc-ed heap.
> And since it's an R value it might get destroyed before execl is finished.
> Assign the result of toStringz to a char* variable and use that in the call.

But execl not goes to Seg.fault. It hangs before call execl..

On Tuesday, 27 December 2016 at 18:00:11 UTC, unDEFER wrote:
> On Tuesday, 27 December 2016 at 17:50:14 UTC, Stefan Koch wrote:
>> The string is allocated on the gc-ed heap.
>> And since it's an R value it might get destroyed before execl is finished.
>> Assign the result of toStringz to a char* variable and use that in the call.
>
> But execl not goes to Seg.fault. It hangs before call execl..

Have you tried assigning it to a variable ?

On Tuesday, 27 December 2016 at 18:01:36 UTC, Stefan Koch wrote:
> Have you tried assigning it to a variable ?

Yes, I have tried, now backtrace of hanged process is:

(gdb) bt
#0  0x00007f4e18260c6d in ?? ()
#1  0x0000000000000000 in ?? ()

On Tuesday, 27 December 2016 at 18:22:12 UTC, unDEFER wrote:
> On Tuesday, 27 December 2016 at 18:01:36 UTC, Stefan Koch wrote:
>> Have you tried assigning it to a variable ?
>
> Yes, I have tried, now backtrace of hanged process is:
>
> (gdb) bt
> #0  0x00007f4e18260c6d in ?? ()
> #1  0x0000000000000000 in ?? ()

BTW, if you are using literals the toStringZ call is not needed.
They are zero terminated by default.

The last backtrace shows that it hangs on the line:

immutable(char) *bash = "/bin/bash".toStringz();

On Tuesday, 27 December 2016 at 17:27:14 UTC, unDEFER wrote:
> Hello I have very simple line with exec-command:
>
> execl("/bin/bash".toStringz(), "/bin/bash".toStringz(), "-c".toStringz(), command.toStringz(), null);
>
> And on this line on toStringz my program sometimes hangs.
> backtrace:
>
> (gdb) bt
> #0  0x00007f3acd535c6d in nanosleep () at ../sysdeps/unix/syscall-template.S:84
> #1  0x000000000066f57e in core.thread.Thread.sleep(core.time.Duration) ()
> #2  0x00000000006b2824 in core.internal.spinlock.SpinLock.yield(ulong) shared
>     ()
> #3  0x00000000006b27c0 in core.internal.spinlock.SpinLock.lock() shared ()
> #4  0x00000000006a7244 in gc.gc.GC.runLocked!(gc.gc.GC.mallocNoSync(ulong, uint, ref ulong, const(TypeInfo)), gc.gc.mallocTime, gc.gc.numMallocs, ulong, uint, ulong, const(TypeInfo)).runLocked(ref ulong, ref uint, ref ulong, ref const(TypeInfo)) ()
> #5  0x00000000006a0bc6 in gc.gc.GC.malloc(ulong, uint, ulong*, const(TypeInfo))
>     ()
> #6  0x00000000006721d3 in gc_qalloc ()
> #7  0x00000000006a99a1 in rt.lifetime.__arrayAlloc(ulong, const(TypeInfo), const(TypeInfo)) ()
> #8  0x000000000067523a in _d_newarrayU ()
> #9  0x0000000000675324 in _d_newarrayiT ()
> #10 0x000000000068fde6 in std.string.toStringz(const(char)[]) ()
> #11 0x000000000068fe79 in std.string.toStringz(const(immutable(char)[])) ()
> #12 0x0000000000592dc9 in unde.command_line.run.fork_command(unde.global_state.CMDGlobalState, immutable(char)[], immutable(char)[], std.concurrency.Tid) (
>     tid=..., command=..., cwd=..., cgs=0x7f3abcdffb80)
>     at source/unde/command_line/run.d:2002
>
> What is it? For what it waits?

What context are you calling this from? Is this in a signal handler? Or from inside a destructor of a GC-owned object?

On Tuesday, 27 December 2016 at 21:33:46 UTC, Marc Schütz wrote:

> What context are you calling this from? Is this in a signal handler? Or from inside a destructor of a GC-owned object?

It is child of my process after fork and before execl. No signal handler, no destructor, no catch-block, usual code.

On Tuesday, 27 December 2016 at 17:27:14 UTC, unDEFER wrote:
> Hello I have very simple line with exec-command:
>
> execl("/bin/bash".toStringz(), "/bin/bash".toStringz(), "-c".toStringz(), command.toStringz(), null);
>
> [...]

Just a note here, string literals are already 0 terminated, so you don't need `toStringz` there.