[Issue 16979] Race in druntime leads to undefined behaviour

2016-12-17 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16979

safety0ff.bugz  changed:

   What|Removed |Added

   Hardware|x86_64  |All
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=15939
   Severity|enhancement |critical

--

[Issue 15939] GC.collect causes deadlock in multi-threaded environment

2016-12-17 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15939

safety0ff.bugz  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=16979

--

[Issue 16979] New: Race in druntime leads to undefined behaviour

2016-12-17 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16979

  Issue ID: 16979
   Summary: Race in druntime leads to undefined behaviour
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: safety0ff.b...@gmail.com

This issue affects Posix (excl. Darwin) druntime implementation of thread
suspend.

Order of events:

Thread 1|   Thread 2

thread_suspendAll
↳suspend(Thread 2)
 reads Thread 2.isRunning as true
 thread_cleanupHandler
 ↳ sets isRunning to false
 Thread 2 exits
 calls pthread_kill with the invalid Thread 2.m_addr


This problem is not present on the normal exit path because Thread 1 holds the
lock for the thread list and thread 2 would block trying to remove itself.

Possible solutions:
#1:
Remove the thread from the list in the cleanup handler.

There is a comment in the current code stating that it is safer to defer this
operation, however, there is no full explanation & rationale for deferring.

#2:
Make Thread.suspend prevent the target thread from returning from
thread_cleanupHandler until after it has called pthread_kill on it.

This may be the cause of #15939.

--

[Issue 16978] [REG2.072.0] pragma(lib) is broken with rdmd

2016-12-17 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16978

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Vladimir Panteleev  ---
https://github.com/dlang/tools/pull/207

--

[Issue 14296] RDMD fails at building a lib when the source is in a subdir

2016-12-17 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14296

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #9 from Vladimir Panteleev  ---
https://github.com/dlang/tools/pull/207

--

[Issue 16962] rdmd --build-only --force -c main.d fails: ./main: No such file or directory

2016-12-17 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16962

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #15 from Vladimir Panteleev  ---
https://github.com/dlang/tools/pull/207

--

[Issue 16978] [REG2.072.0] pragma(lib) is broken with rdmd

2016-12-17 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16978

Vladimir Panteleev  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=16962

--

[Issue 16962] rdmd --build-only --force -c main.d fails: ./main: No such file or directory

2016-12-17 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16962

Vladimir Panteleev  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=16978

--- Comment #14 from Vladimir Panteleev  ---
Another regression: issue 16978

Since there has been no reply from ag0aep6g for 5 days, I am going to revert
that PR and add tests for the regressions. Then they or anyone else can have a
go at it.

--

[Issue 16978] New: [REG2.072.0] pragma(lib) is broken with rdmd

2016-12-17 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16978

  Issue ID: 16978
   Summary: [REG2.072.0] pragma(lib) is broken with rdmd
   Product: D
   Version: D2
  Hardware: All
OS: Linux
Status: NEW
  Severity: regression
  Priority: P1
 Component: tools
  Assignee: nob...@puremagic.com
  Reporter: thecybersha...@gmail.com

// test.d //
pragma(lib, "lzma");

extern(C) uint lzma_version_number();

void main()
{
import std.stdio;
writefln("LZMA version is 0x%08X", lzma_version_number);
}


Introduced in https://github.com/D-Programming-Language/tools/pull/194.

--

[Issue 16595] thisExePath resolves symlinks but this isn't mentioned in docs

2016-12-17 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16595

--- Comment #9 from Jacob Carlborg  ---
I think we're misunderstanding each other. A potential thisExePathUnresolved
function, you obliviously don't that to resolve symbolic links, correct? Do you
want that to return the absolute path? I.e. remove any extra "/", "." or "..".

I think that Phobos, as a standard library, should provide a cross-platform
consistent behavior for the most common use cases. In my opinion thisExePath is
a niche function to begin with, that is most likely not used very often. In
general it also more likely that one would _not_ have a symbolic link.

I think with all these cases combined, if that does not fit your use case I
think you would have to implement that functionality yourself and not it should
not be added to Phobos. The implementation is also very small and already
available, you don't need to figure out how to do it on all platforms.

Andrei, what do you think?

--

[Issue 16977] bad debug info for function default arguments

2016-12-17 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16977

Rainer Schuetze  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Rainer Schuetze  ---
https://github.com/dlang/dmd/pull/6327

--

[Issue 16977] New: bad debug info for function default arguments

2016-12-17 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16977

  Issue ID: 16977
   Summary: bad debug info for function default arguments
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Keywords: symdeb
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: r.sagita...@gmx.de

When compiling this code with debug information for OMF:



void main()
{
foo(1, 2);
}

size_t foo(int x, int y, int z = 3)
{
return x;
}

it results in line number info displayed by the debugger like this:

 1: 
 2: void main()
00402010 55   pushebp  
00402011 8B ECmov ebp,esp  
 3: {
 4: foo(1, 2);
00402013 6A 01push1  
 3: {
 4: foo(1, 2);
00402015 6A 02push2  
 6: 
 7: size_t foo(int x, int y, int z = 3)
00402017 B8 03 00 00 00   mov eax,3  
0040201C E8 07 00 00 00   callcvdefarg@foo (0402028h)  
00402021 31 C0xor eax,eax  
 5: }
00402023 5D   pop ebp  
00402024 C3   ret  

This has issues:

- loading the default argument inherits the location of the function
declaration, so the debugger is prematurely redirected to the source line of
the function before actually calling it. The user thinks the function is
already called, but using "step until return" will stop after returning from
the calling function instead.

- the return address on the stack is considered at line 7, i.e. at the function
declaration. This makes the call stack pretty unusable.

Compiling for COFF is even worse because there is a (gratuitious?) limitation
on increasing line numbers.

--