new(malloc) locks everything in multithreading

[tcak via Digitalmars-d-learn]

This must be my special day that everything I try gets broken.


import core.thread;
import std.stdio;

class ThreadTest{
private core.thread.Thread th;

public this() shared{
th = cast( shared )(
new core.thread.Thread(
cast( void delegate() )( &threadRun )
)
);
}

public void start() shared{
(cast()th).start();
}

private void threadRun() shared{
writeln("It works");
readln();
}
}


void main(){
new shared ThreadTest().start();
char[] abc = new char[4096];
}

=====

Run the program (Release or Debug doesn't matter).

- Mono Application Output -

[Thread debugging using libthread_db enabled]
Using host libthread_db library
\"/lib/x86_64-linux-gnu/libthread_db.so.1\".
[New Thread 0x7ffff75ed700 (LWP 18480)]
[Switching to Thread 0x7ffff75ed700 (LWP 18480)]


In call stack, program comes to "__lll_lock_wait_private () in
/build/buildd/eglibc-2.19/nptl/../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95",
and
this locks everything.

Remove the "char[] abc = ne...." line, and everything is fine.
Remove the "new shared Thre..." line and everything is fine.

I don't want to blame dmd directly because as far as I see from
the search I did with "__lll_lock_wait_private", some C++
programs are having same problem with malloc operation as well.
But still, can this be because of compiler?

[safety0ff via Digitalmars-d-learn]

Post by tcak via Digitalmars-d-learn
I don't want to blame dmd directly because as far as I see from
the search I did with "__lll_lock_wait_private", some C++
programs are having same problem with malloc operation as well.
But still, can this be because of compiler?

Looks like bug #11981 [1], which should be fixed in the latest
versions of the compiler. Which version are you using?

[1] https://issues.dlang.org/show_bug.cgi?id=11981

[tcak via Digitalmars-d-learn]

Post by safety0ff via Digitalmars-d-learn

Post by tcak via Digitalmars-d-learn
I don't want to blame dmd directly because as far as I see
from the search I did with "__lll_lock_wait_private", some C++
programs are having same problem with malloc operation as
well. But still, can this be because of compiler?

Looks like bug #11981 [1], which should be fixed in the latest
versions of the compiler. Which version are you using?
[1] https://issues.dlang.org/show_bug.cgi?id=11981

I am on DMD 2.066 64-bit
Linux 3.13.0-37-generic

[Kagamin via Digitalmars-d-learn]

If it's deterministic, looks more like
https://issues.dlang.org/show_bug.cgi?id=4890
(11981 is not deterministic)

[tcak via Digitalmars-d-learn]

Post by Kagamin via Digitalmars-d-learn
If it's deterministic, looks more like
https://issues.dlang.org/show_bug.cgi?id=4890
(11981 is not deterministic)

Yes, it is deterministic. Run it as many times as you
want, and it does the same thing. I ran it now again, and
still same.

[Kagamin via Digitalmars-d-learn]

Do you see recursive call to malloc in the stack trace?

[tcak via Digitalmars-d-learn]

Post by Kagamin via Digitalmars-d-learn
Do you see recursive call to malloc in the stack trace?

I further simplified the example:

import std.stdio;
import core.thread;

class ThreadTest{
public this(){
new core.thread.Thread( &threadRun ).start();
}

private void threadRun(){
writeln("It works");
readln();
}
}


void main(){
new ThreadTest();
char[] abc = new char[4096];
}


This is what I see on screen:
http://imgur.com/Pv9Rulw

Same result.

[tcak via Digitalmars-d-learn]

Post by tcak via Digitalmars-d-learn

Post by Kagamin via Digitalmars-d-learn
Do you see recursive call to malloc in the stack trace?

import std.stdio;
import core.thread;
class ThreadTest{
public this(){
new core.thread.Thread( &threadRun ).start();
}
private void threadRun(){
writeln("It works");
readln();
}
}
void main(){
new ThreadTest();
char[] abc = new char[4096];
}
http://imgur.com/Pv9Rulw
Same result.

And this is the thread of malloc.
http://imgur.com/e8ofRte

It suspends all threads and cannot get out of there it seems like.

[Kagamin via Digitalmars-d-learn]

Looks like your IDE filters too much. Can you configure it to
filter less and show address locations?

[tcak via Digitalmars-d-learn]

Post by Kagamin via Digitalmars-d-learn
Looks like your IDE filters too much. Can you configure it to
filter less and show address locations?

Main Thread
Loading Image...
Second Thread (TestThread)
Loading Image...

BTW, instead of using Monodevelop with Mono-D, I used same code
on a text
file, and compiled with "dmd test.d", then run with "./test",
then everything
works fine. When I run it with "gdb ./test", then I can see those
errors again.

[tcak via Digitalmars-d-learn]

Post by Kagamin via Digitalmars-d-learn
Looks like your IDE filters too much. Can you configure it to
filter less and show address locations?

This is what I have found:

Main Thread
http://i.imgur.com/6ElZ3Fm.png

Second Thread (TestThread)
http://i.imgur.com/w4y5gYB.png

[Kagamin via Digitalmars-d-learn]

Second Thread (TestThread)
http://i.imgur.com/w4y5gYB.png

Hmm... where is __lll_lock_wait_private now? And how mmap can
hang at all?