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?

On Friday, 24 October 2014 at 02:51:20 UTC, tcak wrote:
>
> 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

On Friday, 24 October 2014 at 03:42:29 UTC, safety0ff wrote:
> On Friday, 24 October 2014 at 02:51:20 UTC, tcak wrote:
>>
>> 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

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

On Friday, 24 October 2014 at 08:47:55 UTC, Kagamin wrote:
> 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.

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

On Friday, 24 October 2014 at 08:55:17 UTC, Kagamin wrote:
> 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.

On Friday, 24 October 2014 at 09:12:57 UTC, tcak wrote:
> On Friday, 24 October 2014 at 08:55:17 UTC, Kagamin wrote:
>> 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.

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

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

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

On Friday, 24 October 2014 at 10:29:10 UTC, Kagamin wrote:
> 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