Corrupted memory? #27955
Assignees
Labels
compiler:codegen
Generation of LLVM IR and native code
GC
Garbage collector
kind:bug
Indicates an unexpected problem or unintended behavior
Comments
|
Locally, I get Putting the whole thing in a function Running it a second time works |
|
On 64-bit Windows: |
|
Still get segmentation violation with 0.7.0-beta.209 on Linux: |
|
In the module I eliminated the EDIT: Further experiments showed that even with the eval the code can be made to run (see below the case where doing |
|
Still fails on Windows 64 bit: Version 0.7.0-beta.212 |
vchuravy
added
the
kind:bug
|
When I do using FinEtools TWICE, the code runs fine. When I run it ONCE, I get a segmentation violation. EDIT: This appears to be quite reproducible. All the FinEtools tests pass on Windows when |
|
Seems like some world age issue then..? |
|
I am not familiar with this subject. Why do you think this might have something to do with the crashes? |
|
0.7.0-beta.233 still fails on Windows 64. |
|
The trick of |
|
@vchuravy , @KristofferC : Is there anything I can do to help find and fix this bug? How is this sort of bug dealt with (what tools are available etc)? |
|
No there is not much you an do without getting into the entrails of the runtime. One thing you could do is minimising the MWE, e.g. reducing FinEtools until it is only a couple of lines that is showing the problem, but that can be somewhat tedious. I am taking a look at it right now, but I don't have much time and can't promise any quick results. |
|
Ok I could reproduce this on the current beta, it looks to me like a missing GC root somewhere, the call to @PetrKryslUCSD is FinEtools doing any funny business with pointers? |
|
@vchuravy : No, not to my knowledge. I don't use pointers in the library itself, and I use a very small number of external packages. |
|
@vchuravy : I turned off all |
|
I could no longer reproduce the crash today with Version 0.7.0-beta.279 (x86_64-w64-mingw32), and with Version 0.7.0-beta2.0 (x86_64-pc-linux-gnu). |
|
With I get a different corruption of memory with this code: The printout says: |
|
@Keno, @vtjnash The above is reproducible with EDIT: @Keno, @vtjnash Bug still reproducible with beta2.43 on Windows. |
|
By way of explanation: With earlier versions of Julia this test passed, as all the orientations are in fact recognized as valid. Correspondingly I think the argument is getting corrupted and an unrecognized orientation is encountered inside T4block. |
|
It is noteworthy that this problem is also something to do with Symbol as argument … Coincidence? |
|
With Linux 64-bit (Version 0.7.0-beta2.26) I get |
|
The bug occurs with the newest Linux Julia as well: |
|
It's the array itself that's getting dropped: |
|
FWIW, this is the bug that @vtjnash asked me a few weeks ago how the GC placement logic handled. The answer is that it doesn't, apparently. I'll play with marking the array pointer derived, which doesn't quite have the correct semantics currently, but I think it can potentially do double duty. |
JeffBezanson
added
compiler:codegen
Keno
added a commit
that referenced
this issue
Jul 24, 2018
The array data pointer is somewhat special. It points to a chunk for memory that is effectively managed by the GC, but is not itself a GC-tracked value. However, it is also not quite an interior pointer into the array, since it may be an external allocation (or at the more immediate IR level it is derived using a load rather than a gep). We could try to make Derived do both, but the semantics turn out to be rather different, so add a new kind of AS `Loaded`, that handles precisely this situation: It roots the object that it was loaded from while it is live. Fixes #27955
Keno
added a commit
that referenced
this issue
Jul 28, 2018
The array data pointer is somewhat special. It points to a chunk for memory that is effectively managed by the GC, but is not itself a GC-tracked value. However, it is also not quite an interior pointer into the array, since it may be an external allocation (or at the more immediate IR level it is derived using a load rather than a gep). We could try to make Derived do both, but the semantics turn out to be rather different, so add a new kind of AS `Loaded`, that handles precisely this situation: It roots the object that it was loaded from while it is live. Fixes #27955
Keno
added a commit
that referenced
this issue
Jul 28, 2018
The array data pointer is somewhat special. It points to a chunk for memory that is effectively managed by the GC, but is not itself a GC-tracked value. However, it is also not quite an interior pointer into the array, since it may be an external allocation (or at the more immediate IR level it is derived using a load rather than a gep). We could try to make Derived do both, but the semantics turn out to be rather different, so add a new kind of AS `Loaded`, that handles precisely this situation: It roots the object that it was loaded from while it is live. Fixes #27955
|
This bug is around no more, it appears. Thanks a bunch! |
|
@Keno : rc2 does not display this bug anymore. |
KristofferC
pushed a commit
that referenced
this issue
Feb 11, 2019
The array data pointer is somewhat special. It points to a chunk for memory that is effectively managed by the GC, but is not itself a GC-tracked value. However, it is also not quite an interior pointer into the array, since it may be an external allocation (or at the more immediate IR level it is derived using a load rather than a gep). We could try to make Derived do both, but the semantics turn out to be rather different, so add a new kind of AS `Loaded`, that handles precisely this situation: It roots the object that it was loaded from while it is live. Fixes #27955
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With
execute
Prints
The text was updated successfully, but these errors were encountered: