Re: Hangs on toStringZ()

2016-12-28 Thread unDEFER via Digitalmars-d
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!


Re: Hangs on toStringZ()

2016-12-28 Thread Nemanja Boric via Digitalmars-d

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.


Re: Hangs on toStringZ()

2016-12-28 Thread unDEFER via Digitalmars-d
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.



Re: Hangs on toStringZ()

2016-12-28 Thread unDEFER via Digitalmars-d
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.


Re: Hangs on toStringZ()

2016-12-28 Thread Nemanja Boric via Digitalmars-d
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?


Re: Hangs on toStringZ()

2016-12-28 Thread Nemanja Boric via Digitalmars-d
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.


Re: Hangs on toStringZ()

2016-12-28 Thread Nemanja Boric via Digitalmars-d

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.


Re: Hangs on toStringZ()

2016-12-27 Thread unDEFER via Digitalmars-d

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.


Re: Hangs on toStringZ()

2016-12-27 Thread Marc Schütz via Digitalmars-d

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  0x7f3acd535c6d in nanosleep () at 
../sysdeps/unix/syscall-template.S:84
#1  0x0066f57e in 
core.thread.Thread.sleep(core.time.Duration) ()
#2  0x006b2824 in 
core.internal.spinlock.SpinLock.yield(ulong) shared

()
#3  0x006b27c0 in 
core.internal.spinlock.SpinLock.lock() shared ()
#4  0x006a7244 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  0x006a0bc6 in gc.gc.GC.malloc(ulong, uint, ulong*, 
const(TypeInfo))

()
#6  0x006721d3 in gc_qalloc ()
#7  0x006a99a1 in rt.lifetime.__arrayAlloc(ulong, 
const(TypeInfo), const(TypeInfo)) ()

#8  0x0067523a in _d_newarrayU ()
#9  0x00675324 in _d_newarrayiT ()
#10 0x0068fde6 in std.string.toStringz(const(char)[]) ()
#11 0x0068fe79 in 
std.string.toStringz(const(immutable(char)[])) ()
#12 0x00592dc9 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?


Re: Hangs on toStringZ()

2016-12-27 Thread unDEFER via Digitalmars-d

The last backtrace shows that it hangs on the line:

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


Re: Hangs on toStringZ()

2016-12-27 Thread Stefan Koch via Digitalmars-d

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  0x7f4e18260c6d in ?? ()
#1  0x in ?? ()


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


Re: Hangs on toStringZ()

2016-12-27 Thread unDEFER via Digitalmars-d

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  0x7f4e18260c6d in ?? ()
#1  0x in ?? ()


Re: Hangs on toStringZ()

2016-12-27 Thread unDEFER via Digitalmars-d

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..


Re: Hangs on toStringZ()

2016-12-27 Thread Stefan Koch via Digitalmars-d

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 ?


Re: Hangs on toStringZ()

2016-12-27 Thread Stefan Koch via Digitalmars-d

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.


Hangs on toStringZ()

2016-12-27 Thread unDEFER via Digitalmars-d

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  0x7f3acd535c6d in nanosleep () at 
../sysdeps/unix/syscall-template.S:84
#1  0x0066f57e in 
core.thread.Thread.sleep(core.time.Duration) ()
#2  0x006b2824 in 
core.internal.spinlock.SpinLock.yield(ulong) shared

()
#3  0x006b27c0 in core.internal.spinlock.SpinLock.lock() 
shared ()
#4  0x006a7244 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  0x006a0bc6 in gc.gc.GC.malloc(ulong, uint, ulong*, 
const(TypeInfo))

()
#6  0x006721d3 in gc_qalloc ()
#7  0x006a99a1 in rt.lifetime.__arrayAlloc(ulong, 
const(TypeInfo), const(TypeInfo)) ()

#8  0x0067523a in _d_newarrayU ()
#9  0x00675324 in _d_newarrayiT ()
#10 0x0068fde6 in std.string.toStringz(const(char)[]) ()
#11 0x0068fe79 in 
std.string.toStringz(const(immutable(char)[])) ()
#12 0x00592dc9 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?