On Monday, 16 April 2018 at 16:36:48 UTC, Matthias Klumpp wrote:
[...]
The code uses std.typecons.scoped occasionally, does no GC
allocations in destructors and does nothing to mess with the GC
in general. There are a few calls to GC.add/removeRoot in the
gir-to-d generated code (ObjectG.d), b
On Monday, 16 April 2018 at 16:36:48 UTC, Matthias Klumpp wrote:
The code uses std.typecons.scoped occasionally, does no GC
allocations in destructors and does nothing to mess with the GC
in general.
What do you use destructors for?
Other stuff to try:
1. run application compiled on debian against ubuntu libs
2. can you mix dependencies from debian and ubuntu?
On Tuesday, 17 April 2018 at 08:23:07 UTC, Kagamin wrote:
Other stuff to try:
1. run application compiled on debian against ubuntu libs
2. can you mix dependencies from debian and ubuntu?
I haven't tried that yet (next on my todo list), if I do run the
program compiled with address sanitizer o
You can call GC.collect at some points in the program to see if
they can trigger the crash
https://dlang.org/library/core/memory/gc.collect.html
If you link against debug druntime, GC can check invariants for
correctness of its structures. There's a number of debugging
options for GC, though no
On Wednesday, 18 April 2018 at 10:15:49 UTC, Kagamin wrote:
You can call GC.collect at some points in the program to see if
they can trigger the crash
I already do that, and indeed I get crashes. I could throw those
calls into every function though, or make a minimal pool size,
maybe that yie
On Wednesday, 18 April 2018 at 10:15:49 UTC, Kagamin wrote:
There's a number of debugging options for GC, though not sure
which
ones are enabled in default debug build of druntime
Speaking for LDC, none are, they all need to be enabled
explicitly. There's a whole bunch of them
(https://githu
Am Wed, 18 Apr 2018 17:40:56 + schrieb Matthias Klumpp:
>
> The crashes always appear in
> https://github.com/dlang/druntime/blob/master/src/gc/impl/conservative/
gc.d#L1990
>
The important point to note here is that this is not one of these 'GC
collected something because it was not reacha
On Monday, 16 April 2018 at 16:36:48 UTC, Matthias Klumpp wrote:
...
This reminds me of (otherwise unrelated) problems I had involving
Linux 4.15.
If you feel out of ideas, I suggest you take a look at the
kernels. It might
be that Ubuntu is turning some security-related knob in a
differe
On Wednesday, 18 April 2018 at 18:55:48 UTC, kinke wrote:
On Wednesday, 18 April 2018 at 10:15:49 UTC, Kagamin wrote:
There's a number of debugging options for GC, though not sure
which
ones are enabled in default debug build of druntime
Speaking for LDC, none are, they all need to be enabled
On Wednesday, 18 April 2018 at 20:40:52 UTC, Matthias Klumpp
wrote:
[...]
If possible, I'd give static linking a try.
I tried that, with at least linking druntime and phobos
statically. I did not, however, link all the things statically.
That is something to try (at least statically linking a
On Wednesday, 18 April 2018 at 20:36:03 UTC, Johannes Pfau wrote:
Actually this sounds very familiar:
https://github.com/D-Programming-GDC/GDC/pull/236
Interesting, but I don't think it applies here. Both start and
end addresses are 16-bytes aligned, and both cannot be accessed
according to t
On Wednesday, 18 April 2018 at 20:36:03 UTC, Johannes Pfau wrote:
[...]
Actually this sounds very familiar:
https://github.com/D-Programming-GDC/GDC/pull/236
it took us quite some time to reduce and debug this:
https://github.com/D-Programming-GDC/GDC/pull/236/commits/
5021b8d031fcacac52ee4
On Wednesday, 18 April 2018 at 22:12:12 UTC, kinke wrote:
On Wednesday, 18 April 2018 at 20:36:03 UTC, Johannes Pfau
wrote:
Actually this sounds very familiar:
https://github.com/D-Programming-GDC/GDC/pull/236
Interesting, but I don't think it applies here. Both start and
end addresses are 16
Am Wed, 18 Apr 2018 22:24:13 + schrieb Matthias Klumpp:
> On Wednesday, 18 April 2018 at 22:12:12 UTC, kinke wrote:
>> On Wednesday, 18 April 2018 at 20:36:03 UTC, Johannes Pfau wrote:
>>> Actually this sounds very familiar:
>>> https://github.com/D-Programming-GDC/GDC/pull/236
>>
>> Interesti
Am Thu, 19 Apr 2018 06:33:27 + schrieb Johannes Pfau:
>
> Generally if you produced a crash in gdb it should be reproducible if
> you restart the program in gdb. So once you have a crash, you should be
> able to restart the program and look at the _dso_registry and see the
> same addresses so
Am Thu, 19 Apr 2018 07:04:14 + schrieb Johannes Pfau:
> Am Thu, 19 Apr 2018 06:33:27 + schrieb Johannes Pfau:
>
>
>> Generally if you produced a crash in gdb it should be reproducible if
>> you restart the program in gdb. So once you have a crash, you should be
>> able to restart the pro
On Wednesday, 18 April 2018 at 17:40:56 UTC, Matthias Klumpp
wrote:
On Wednesday, 18 April 2018 at 10:15:49 UTC, Kagamin wrote:
You can call GC.collect at some points in the program to see
if they can trigger the crash
I already do that, and indeed I get crashes. I could throw
those calls int
On Wednesday, 18 April 2018 at 17:40:56 UTC, Matthias Klumpp
wrote:
I get compile errors for the INVARIANT option, and I don't
actually know how to deal with those properly:
```
src/gc/impl/conservative/gc.d(1396): Error: shared mutable
method core.internal.spinlock.SpinLock.lock is not callabl
On Wednesday, 18 April 2018 at 22:24:13 UTC, Matthias Klumpp
wrote:
size_t memSize = pooltable.maxAddr - minAddr;
(https://github.com/ldc-developers/druntime/blob/ldc/src/gc/impl/conservative/gc.d#L1982
)
That wouldn't make sense for a pool size...
The machine this is running on has 16G memory,
foreach(i;0..1)
10 is too much
On Thursday, 19 April 2018 at 08:30:45 UTC, Kagamin wrote:
On Wednesday, 18 April 2018 at 22:24:13 UTC, Matthias Klumpp
wrote:
size_t memSize = pooltable.maxAddr - minAddr;
(https://github.com/ldc-developers/druntime/blob/ldc/src/gc/impl/conservative/gc.d#L1982
)
That wouldn't make sense for a
On Thursday, 19 April 2018 at 17:01:48 UTC, Matthias Klumpp wrote:
Something that maybe is relevant though: I occasionally get the
following SIGABRT crash in the tool on machines which have the
SIGSEGV crash:
```
Thread 53 "appstream-gener" received signal SIGABRT, Aborted.
[Switching to Thread
On Thursday, 19 April 2018 at 18:45:41 UTC, kinke wrote:
On Thursday, 19 April 2018 at 17:01:48 UTC, Matthias Klumpp
wrote:
Something that maybe is relevant though: I occasionally get
the following SIGABRT crash in the tool on machines which have
the SIGSEGV crash:
```
Thread 53 "appstream-gen
On Friday, 20 April 2018 at 00:11:25 UTC, Matthias Klumpp wrote:
[...]
Jup, I did that already, it just took a really long time to run
because when I made the change to print errno [...]
I forgot to mention that, the error code was 12, ENOMEM, so this
is actually likely not a relevant issue a
On Friday, 20 April 2018 at 00:11:25 UTC, Matthias Klumpp wrote:
On Thursday, 19 April 2018 at 18:45:41 UTC, kinke wrote:
[...]
Jup, I did that already, it just took a really long time to run
because when I made the change to print errno I also enabled
detailed GC profiling (via the PRINTF*
On Monday, 16 April 2018 at 16:36:48 UTC, Matthias Klumpp wrote:
#2 0x751341c8 in
_D2rt4util9container5treap__T5TreapTS2gc11gcinterface5RangeZQBf7opApplyMFNbMDFNbKQBtZiZ9__lambda2MFNbKxSQCpQCpQCfZi (e=...) at treap.d:47
dg = {context = 0x7fffc140 "\320\065\206", funcptr
= 0x
On Friday, 20 April 2018 at 05:32:32 UTC, Dmitry Olshansky wrote:
On Friday, 20 April 2018 at 00:11:25 UTC, Matthias Klumpp wrote:
On Thursday, 19 April 2018 at 18:45:41 UTC, kinke wrote:
[...]
Jup, I did that already, it just took a really long time to
run because when I made the change to
On Friday, 20 April 2018 at 18:30:30 UTC, Matthias Klumpp wrote:
On Friday, 20 April 2018 at 05:32:32 UTC, Dmitry Olshansky
wrote:
On Friday, 20 April 2018 at 00:11:25 UTC, Matthias Klumpp
wrote:
On Thursday, 19 April 2018 at 18:45:41 UTC, kinke wrote:
[...]
[...]
I think the order of opera
On Friday, 20 April 2018 at 19:32:24 UTC, Matthias Klumpp wrote:
On Friday, 20 April 2018 at 18:30:30 UTC, Matthias Klumpp wrote:
[...]
Turns out that was indeed the case! I created a small testcase
which managed to very reliably reproduce the issue on all
machines that I tested it on. After
30 matches
Mail list logo
