Re: How to debug (potential) GC bugs?

Am Sun, 25 Sep 2016 16:23:11 + schrieb Matthias Klumpp : > Hello! > I am working together with others on the D-based > appstream-generator[1] project, which is generating software > metadata for "software centers" and other package-manager > functionality on Linux

Re: How to debug (potential) GC bugs?

On Saturday, 1 October 2016 at 00:06:05 UTC, Matthias Klumpp wrote: So, this problem is: A) A compiler / DRuntime bug, or B) A bug in my code (not) triggered by a certain compiler / DRuntime We actually did change druntime recently to no longer fail when using GC.free from a finalizer

Re: How to debug (potential) GC bugs?

On Tuesday, 4 October 2016 at 08:14:37 UTC, Ilya Yaroshenko wrote: Probably related issue: https://issues.dlang.org/show_bug.cgi?id=15939 Crashes in a finalizer, likely not related to the dead-lock bug.

Re: How to debug (potential) GC bugs?

On Sunday, 25 September 2016 at 16:23:11 UTC, Matthias Klumpp wrote: Hello! I am working together with others on the D-based appstream-generator[1] project, which is generating software metadata for "software centers" and other package-manager functionality on Linux distributions, and is used

Re: How to debug (potential) GC bugs?

If it's heap corruption, GC has debugging option -debug=SENTINEL - for buffer overrun checks. Also that particular stack trace shows that object being destroyed is allocated in bin 512, i.e. its size is between 256 and 512 bytes.

Re: How to debug (potential) GC bugs?

On Sunday, 25 September 2016 at 16:23:11 UTC, Matthias Klumpp wrote: For Ubuntu, some modifications on the code were needed, and apparently for them the code is currently crashing in the GC collection thread: http://paste.debian.net/840490/ Oh, wait, what do you mean by crashing?

Re: How to debug (potential) GC bugs?

On Saturday, 1 October 2016 at 00:06:05 UTC, Matthias Klumpp wrote: I do none of those things in my code though... `grep "~this" *.d` gives nothing? It can be a struct with destructor stored in a class. Can you observe the error? Try to set a breakpoint at onInvalidMemoryOperationError

Re: How to debug (potential) GC bugs?

Does it crash only in rt_finalize2? It calls the class destructor, and the destructor must not allocate or touch GC in any way because the GC doesn't yet support allocation during collection.

Re: How to debug (potential) GC bugs?

On Sunday, 25 September 2016 at 16:23:11 UTC, Matthias Klumpp wrote: Hello! I am working together with others on the D-based appstream-generator[1] project, which is generating software metadata for "software centers" and other package-manager functionality on Linux distributions, and is used

Re: How to debug (potential) GC bugs?

On Sunday, 25 September 2016 at 16:23:11 UTC, Matthias Klumpp wrote: Hello! I am working together with others on the D-based appstream-generator[1] project, which is generating software metadata for "software centers" and other package-manager functionality on Linux distributions, and is used

Re: How to debug (potential) GC bugs?

Am Sun, 25 Sep 2016 16:23:11 + schrieb Matthias Klumpp : > So, I would like to know the following things: > > 1) Is there any caveat when linking to C libraries and using the > GC in a project? So far, it seems to be working well, but there > have been a few cases

How to debug (potential) GC bugs?

Hello! I am working together with others on the D-based appstream-generator[1] project, which is generating software metadata for "software centers" and other package-manager functionality on Linux distributions, and is used by default on Debian, Ubuntu and Arch Linux. For Ubuntu, some