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
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
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();
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(){
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:46:57 UTC, tcak wrote:
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
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
On Friday, 24 October 2014 at 10:46:57 UTC, tcak wrote:
Second Thread (TestThread)
http://i.imgur.com/w4y5gYB.png
Hmm... where is __lll_lock_wait_private now? And how mmap can
hang at all?
On Friday, 24 October 2014 at 10:49:42 UTC, tcak wrote:
On Friday, 24 October 2014 at 10:46:57 UTC, tcak wrote:
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
On Friday, 24 October 2014 at 12:38:48 UTC, Kagamin wrote:
On Friday, 24 October 2014 at 10:46:57 UTC, tcak wrote:
Second Thread (TestThread)
http://i.imgur.com/w4y5gYB.png
Hmm... where is __lll_lock_wait_private now? And how mmap can
hang at all?
Here it is.
http://i.imgur.com/5ZDuYRF.png
On Friday, 24 October 2014 at 16:51:02 UTC, Kapps wrote:
On Friday, 24 October 2014 at 10:49:42 UTC, tcak wrote:
Not sure if this is the same issue, but by default gdb breaks
on signals that the GC uses, which would explain why it's
breaking in gdb but not normally.
What happens if you try:
On Friday, 24 October 2014 at 18:38:39 UTC, tcak wrote:
On Friday, 24 October 2014 at 16:51:02 UTC, Kapps wrote:
On Friday, 24 October 2014 at 10:49:42 UTC, tcak wrote:
Not sure if this is the same issue, but by default gdb breaks
on signals that the GC uses, which would explain why it's
On Friday, 24 October 2014 at 21:02:05 UTC, Kapps wrote:
Yes, GDB is stopping on SIGUSR1 / SIGUSR2 since that's the
default settings. D's GC uses these signals for suspending /
resuming threads during a collection. You need to type what I
said above, prior to typing 'run'.
I took a look at
On Friday, 24 October 2014 at 21:02:05 UTC, Kapps wrote:
On Friday, 24 October 2014 at 18:38:39 UTC, tcak wrote:
On Friday, 24 October 2014 at 16:51:02 UTC, Kapps wrote:
This is what I did on shell: (I put some spaces for
readability)
tolga@tolga:~/dev/d/bug$ dmd -gc -debug test.d
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(
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
18 matches
Mail list logo
