[Issue 5455] ICE(cgcod.c): Optimization (register allocation?) regression in DMD 1.065
http://d.puremagic.com/issues/show_bug.cgi?id=5455 --- Comment #5 from Don clugd...@yahoo.com.au 2011-01-25 00:27:34 PST --- The bug was triggered by this change to SliceExp::toElem() (now line 4426): --- elem *eptr = array_toPtr(e1-type, e); -elem *elength = el_bin(OPmin, TYint, eupr, elwr2); +elem *elength = el_bin(OPmin, TYsize_t, eupr, elwr2); eptr = el_bin(OPadd, TYnptr, eptr, el_bin(OPmul, TYsize_t, el_copytree(elwr2), el_long(TYsize_t, sz))); e = el_pair(TYdarray, elength, eptr); e = el_combine(elwr, e); e = el_combine(einit, e); --- Reverting this change removes the ICE. TYsize_t is a TYuint, rather than a TYint. Still, I don't understand why it makes any difference. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5482] New: Crash with align(0)
http://d.puremagic.com/issues/show_bug.cgi?id=5482
Summary: Crash with align(0)
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-01-25 02:59:10 PST ---
This crashes DMD 2.051:
align(0) struct Foo {
char c;
int i;
}
void main() {
Foo f = Foo();
}
---
This causes an Access Violation with DMD 2.051:
align(0) struct Foo {
int i, j;
}
void main() {
Foo f = Foo();
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5483] New: Missing mcontext_t for X86_64
http://d.puremagic.com/issues/show_bug.cgi?id=5483 Summary: Missing mcontext_t for X86_64 Product: D Version: unspecified Platform: x86_64 OS/Version: FreeBSD Status: NEW Severity: normal Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: d...@dawgfoto.de --- Comment #0 from d...@dawgfoto.de 2011-01-25 10:40:40 PST --- Created an attachment (id=876) git format-patch I have added the missing mcontext_t for FreeBSD version X86_64. This was taken from my 8.0-FreeBSD machine/ucontext.h header. I've tested that by comparing offsets of members with the c version and using swapcontext. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4307] spawn()'ed thread doesn't terminate
http://d.puremagic.com/issues/show_bug.cgi?id=4307 Sean Kelly s...@invisibleduck.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||s...@invisibleduck.org --- Comment #11 from Sean Kelly s...@invisibleduck.org 2011-01-25 10:53:43 PST --- I don't think threads can start as detached, because the GC needs to interact with them. I'll give this another look though. I also fixed a major timing-related bug since 2.051 was released, which may help here as wells. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5483] Missing mcontext_t for X86_64
http://d.puremagic.com/issues/show_bug.cgi?id=5483 Sean Kelly s...@invisibleduck.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||s...@invisibleduck.org -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4307] spawn()'ed thread doesn't terminate
http://d.puremagic.com/issues/show_bug.cgi?id=4307 --- Comment #12 from Jonathan M Davis jmdavisp...@gmx.com 2011-01-25 11:32:30 PST --- I don't know exactly what the GC requires with regards to threads, but when I was talking about starting a thread as detached, I meant detached in the pthreads sense, not the GC sense, like core.thread generally talks about with functions like thread_detachThis(). Spawned threads obviously need to be attached to the GC. The problem is that they can't have to be joined unless there's somehow a thread somewhere which cleans them up. Spawned threads are essentially supposed to clean themselves up and go away when they terminate, and that essentially means that they need to be detached in the pthread sense, since the programmer isn't going to have the parent thread join it when it's done. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5484] New: GC segfaults on FreeBSD 64 / scanning issues for .data and .bss sections
http://d.puremagic.com/issues/show_bug.cgi?id=5484
Summary: GC segfaults on FreeBSD 64 / scanning issues for .data
and .bss sections
Product: D
Version: D2
Platform: All
OS/Version: FreeBSD
Status: NEW
Severity: normal
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: d...@dawgfoto.de
--- Comment #0 from d...@dawgfoto.de 2011-01-25 11:34:53 PST ---
Created an attachment (id=877)
elf64-x86-64-freebsd
IMHO FreeBSD is missing _data__start/_data__end/_bss_start__/_bss_end__
symbols.
The current strategy is to use etext and _end as scanning range.
From compiling void main() {}
-m32:
nm out | grep etext - 08055b38 A etext
nm out | grep _end - 0805ba04 A _end
-m64:
nm out | grep etext - 00411012 A etext
nm out | grep _end - 00619988 A _end
This is not optimal as it spans over some read only sections but it's a minor
issue for 32.
With elf64-x86-64-freebsd there is a big non-readable area between .eh_frame
and .tdata. This leads to segfaulting when running the garbage collector.
I don't know any portable/official solution to this but observed that _progname
is always the first symbol in .data for 32/64 bit.
The boehm collector is installing a signal handler and tries to read from _end
upwards until it fails.
I've appended objdump section headers.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5484] GC segfaults on FreeBSD 64 / scanning issues for .data and .bss sections
http://d.puremagic.com/issues/show_bug.cgi?id=5484 --- Comment #1 from d...@dawgfoto.de 2011-01-25 11:35:56 PST --- Created an attachment (id=878) elf32-i386-freebsd -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5485] New: TLS sections handled incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=5485 Summary: TLS sections handled incorrectly Product: D Version: D2 Platform: Other OS/Version: FreeBSD Status: NEW Severity: normal Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: d...@dawgfoto.de --- Comment #0 from d...@dawgfoto.de 2011-01-25 11:53:08 PST --- Created an attachment (id=879) git format-patch In src/core/thread.d: _tlsstart/_tlsend should be handled same as for linux elf. -extern void* _tlsstart; -extern void* _tlsend; +extern __thread int _tlsstart; +extern __thread int _tlsend; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5477] std.signals should have the ability to fire events asynchronously
http://d.puremagic.com/issues/show_bug.cgi?id=5477 Lukasz Wrzosek luk.wrzo...@gmail.com changed: What|Removed |Added CC||luk.wrzo...@gmail.com --- Comment #1 from Lukasz Wrzosek luk.wrzo...@gmail.com 2011-01-25 12:23:25 PST --- What exactly you mean by 'are asynchronous'? AFAIK the current implementation is just synchronous, and also i believe there is no possibility to emit signal to other thread. Signal/Slot mechanism is not event based as in Qt. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Re: spawn bug?
Sean Kelly Wrote: This one is weird, and doesn't appear related to 4307. One of the threads (thread A) is in a GC collection and blocked trying to acquire the mutex protecting the global thread list within thread_resumeAll. Another thread (thread B) is also blocked trying to acquire this mutex for other reasons. My best guess is that pthread_mutex in OSX is trying to give ownership of the lock to thread B, and since thread B is suspended it effectively blocks thread A from acquiring it to resume execution after the GC cycle. After some testing, it looks like I was right. I have a fix for this, but it's far from ideal (though the diff is small): require everything but thread_resumeAll to acquire two locks in sequence, while thread_resumeAll only acquires the second. I'll try to come up with something better.
[Issue 5455] ICE(cgcod.c): Optimization (register allocation?) regression in DMD 1.065
http://d.puremagic.com/issues/show_bug.cgi?id=5455 --- Comment #6 from Don clugd...@yahoo.com.au 2011-01-25 13:07:25 PST --- I think what's happened, is that a minor change to support 64 bits has triggered a latent bug in the backend. Basically, cgreg_assign() in cgreg.c thinks there are enough free registers. But allocreg() in cgcod.c can't find one. Although it is called with two available registers, one of them is EBP, and EBP is disallowed in line 1910. So these two functions are inconsistent. I think the problem may be in creg_assign(). It thinks it has freed up a register (EBX) which is used for 'this'. But (if I've correctly understood what the code is doing) the same register seems to be used in a double-reg combo. Seems a bit similar to bug 4443. If I'm correct, then a solution to this bug would be to check if the register is also part of a double-reg variable, before marking it as freed-up. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5485] TLS sections handled incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=5485 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||INVALID --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2011-01-25 17:09:58 PST --- __thread is the default for D2, so this patch doesn't do anything. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5486] Missing define for running dmd as 64-bit
http://d.puremagic.com/issues/show_bug.cgi?id=5486 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2011-01-25 17:55:41 PST --- https://github.com/D-Programming-Language/dmd/commit/0ec3b3aad88a318f639a4cbdec75aa4370f2f0cf https://github.com/D-Programming-Language/dmd/commit/4ecec00a812dee90c6d4a55c6b3c6ce5ef31977f -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5485] TLS sections handled incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=5485
Brad Roberts bra...@puremagic.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||bra...@puremagic.com
Resolution|INVALID |
--- Comment #2 from Brad Roberts bra...@puremagic.com 2011-01-25 18:59:51 PST
---
So, the obvious follow up here is that the existing __thread parts from the
other _tlsstart and _tlsend declarations should be yanked as pointless:
diff --git a/src/core/thread.d b/src/core/thread.d
index a317306..911efb3 100644
--- a/src/core/thread.d
+++ b/src/core/thread.d
@@ -130,8 +130,8 @@ version( Windows )
// these are defined in dm\src\win32\tlsseg.asm by DMC.
extern (C)
{
-extern __thread int _tlsstart;
-extern __thread int _tlsend;
+extern int _tlsstart;
+extern int _tlsend;
}
}
else
@@ -251,8 +251,8 @@ else version( Posix )
{
extern (C)
{
-extern __thread int _tlsstart;
-extern __thread int _tlsend;
+extern int _tlsstart;
+extern int _tlsend;
}
}
else version( OSX )
Also, how about the int vs void* difference? From the look of the usage
pattern, it probably doesn't matter, but it does stand out as a difference.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
Re: spawn bug?
I tried to get a bugzilla account but it never emailed me the verification. I'll try again and then try to figure out how to post this there. Thanks for looking into it. Adam
[Issue 5488] New: Spawned threads hang in a way that suggests allocation or gc issue
http://d.puremagic.com/issues/show_bug.cgi?id=5488 Summary: Spawned threads hang in a way that suggests allocation or gc issue Product: D Version: D2 Platform: x86 OS/Version: Mac OS X Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: adam_conner_...@yahoo.com --- Comment #0 from Adam Conner-Sax adam_conner_...@yahoo.com 2011-01-25 20:05:49 PST --- Created an attachment (id=882) code to demonstrate the issue described above The attached program hangs more often than not during the second set of spawns (using dmd 2.051 on OSX). The thread functions do nothing but allocate a large array and then exit. In one case the array is an Array!double (from std.container) and in the other it is a built-in double[]. In the second case, a large enough array will cause the program to hang. Sean Kelly has already done some investigating, quoting from his responses: 1) This one is weird, and doesn't appear related to 4307. One of the threads (thread A) is in a GC collection and blocked trying to acquire the mutex protecting the global thread list within thread_resumeAll. Another thread (thread B) is also blocked trying to acquire this mutex for other reasons. My best guess is that pthread_mutex in OSX is trying to give ownership of the lock to thread B, and since thread B is suspended it effectively blocks thread A from acquiring it to resume execution after the GC cycle. 2) After some testing, it looks like I was right. I have a fix for this, but it's far from ideal (though the diff is small): require everything but thread_resumeAll to acquire two locks in sequence, while thread_resumeAll only acquires the second. I'll try to come up with something better. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Re: spawn bug?
Okay, figured out puremagic a little. http://d.puremagic.com/issues/show_bug.cgi?id=5488
