On Wednesday, 28 December 2016 at 11:21:34 UTC, Nemanja Boric wrote:
> 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.

Ah, I just saw Stefan already made this remark, sorry.

Given that you're in a forked process, it could be that you've just got your GC in a broken state (internal was locked prior to forking, and now you can't get the GC ever, since there's nothing to unlock it.

What you should do is following:

1. Allocate all needed data, convert all D strings into C strings, etc.
2. fork
3. exec immediately, not using anything from standard library between 2 and 3.

On Wednesday, 28 December 2016 at 11:30:22 UTC, Nemanja Boric wrote:
> On Wednesday, 28 December 2016 at 11:21:34 UTC, Nemanja Boric wrote:
>> On Tuesday, 27 December 2016 at 17:27:14 UTC, unDEFER wrote:
>>> [...]
>>
>> Just a note here, string literals are already 0 terminated, so you don't need `toStringz` there.
>
> Ah, I just saw Stefan already made this remark, sorry.
>
> Given that you're in a forked process, it could be that you've just got your GC in a broken state (internal was locked prior to forking, and now you can't get the GC ever, since there's nothing to unlock it.
>
> What you should do is following:
>
> 1. Allocate all needed data, convert all D strings into C strings, etc.
> 2. fork
> 3. exec immediately, not using anything from standard library between 2 and 3.

My other guess is that you're using D threads in your application?

On Wednesday, 28 December 2016 at 11:30:22 UTC, Nemanja Boric wrote:
> What you should do is following:
>
> 1. Allocate all needed data, convert all D strings into C strings, etc.
> 2. fork
> 3. exec immediately, not using anything from standard library between 2 and 3.

OK, thank you.. I'm trying it and still haven't hanging.

On Wednesday, 28 December 2016 at 11:32:09 UTC, Nemanja Boric wrote:
> My other guess is that you're using D threads in your application?

Of course I'm using D threads, but with it all is normally.

On Wednesday, 28 December 2016 at 12:30:03 UTC, unDEFER wrote:
> On Wednesday, 28 December 2016 at 11:32:09 UTC, Nemanja Boric wrote:
>> My other guess is that you're using D threads in your application?
>
> Of course I'm using D threads, but with it all is normally.

Right, nothing wrong with threads, but super tricky to combine it with fork. So, it could be that one of your threads is using GC at the point of the forking, so it keeps the GC locked. Now you fork, and _all your threads don't exist anymore, they are vanished, and if you don't do some clever stuff in atfork handler, there will be no cleanup_ - you just have copy of the thread that called fork. So, the thread that should release GC lock doesn't exist anymore, and there's nothing to release mutex, and it will stay locked forever in your forked process.

On Wednesday, 28 December 2016 at 12:39:46 UTC, Nemanja Boric wrote:
> Right, nothing wrong with threads, but super tricky to combine it with fork. So, it could be that one of your threads is using GC at the point of the forking, so it keeps the GC locked. Now you fork, and _all your threads don't exist anymore, they are vanished, and if you don't do some clever stuff in atfork handler, there will be no cleanup_ - you just have copy of the thread that called fork. So, the thread that should release GC lock doesn't exist anymore, and there's nothing to release mutex, and it will stay locked forever in your forked process.

Thanks a lot for such detailed explanation!