Discussion:
Possible internal corruption
(too old to reply)
J. Gareth Moreton
2018-06-29 07:28:01 UTC
Permalink
Hi everyone,
I'm having some difficulty with fixing issue #33909, and I may have
stumbled a more severe problem that might be causing some internal
corruption.  I have raised a new issue about it, #33926.  Given the
recent e-mail from Pierre, there might be something amiss going on inside
the compiler that goes deeper than jump optimisations.
A clue that leads me to believe there's internal corruption is that a
produced .s file yields an alignment field of ".balign 119,0x90", which
should never happen.  Furthermore, letting the debugger continue after it
hits the compiler abort exception causes a SIGSEGV in a destructor.
I apologise if it is indeed my optimisation that is causing these
problems, but I'm at a bit of a loss as to where to go from here.

Gareth
Martok
2018-06-29 09:27:33 UTC
Permalink
A clue that leads me to believe there's internal corruption is that a produced
.s file yields an alignment field of ".balign 119,0x90", which should never
happen.
Could you set a breakpoint on aggas.pas:721 (the call to doalign) with a
conditional on "tai_align_abstract(hp).aligntype=119" and check what the actual
type of hp is? It could be that at some point a node gets its typ changed in an
invalid way?
aligntype should be either one of 2^[0..5], never something else...

This is where AddressSanitizer support would be *nice*.
--
Regards,
Martok

Ceterum censeo b32079 esse sanandam.

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/ma
J. Gareth Moreton
2018-06-29 09:05:14 UTC
Permalink
It turns out that it's invalid memory.  Trying to call "ClassName" raises
an access violation (other aligns work fine).  There's a dangling pointer
somewhere.  I found one in the CMOV optimisation code, but that hasn't
fixed the crash.

Gareth
Post by J. Gareth Moreton
A clue that leads me to believe there's internal corruption is that a
produced
Post by J. Gareth Moreton
.s file yields an alignment field of ".balign 119,0x90", which should
never
Post by J. Gareth Moreton
happen.
Could you set a breakpoint on aggas.pas:721 (the call to doalign) with a
conditional on "tai_align_abstract(hp).aligntype=119" and check what the
actual
type of hp is? It could be that at some point a node gets its typ changed
in an
invalid way?
aligntype should be either one of 2^[0..5], never something else...

This is where AddressSanitizer support would be *nice*.

--
Regards,
Martok

Ceterum censeo b32079 esse sanandam.

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org [1]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[2]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



Links:
------
[1] mailto:fpc-***@lists.freepascal.org
[2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
J. Gareth Moreton
2018-06-29 11:09:18 UTC
Permalink
So I've made a breakthrough. The memory corruption is due to both parts of
the CMOV optimization under OptPass2Jcc, not my Jcc addition (although it
might have unintentionally accentuated it). The first part sets p to a
dangling pointer, while the 2nd part is a little more complicated, but I'll
try to spell everything out once I finish testing my new patch and see if
I've eliminated all of my crashes

Gareth

On Fri 29/06/18 10:05 , "J. Gareth Moreton" ***@moreton-family.com
sent:
It turns out that it's invalid memory.  Trying to call "ClassName"
raises an access violation (other aligns work fine).  There's a dangling
pointer somewhere.  I found one in the CMOV optimisation code, but that
hasn't fixed the crash.

Gareth
Post by J. Gareth Moreton
A clue that leads me to believe there's internal corruption is that a
produced
Post by J. Gareth Moreton
.s file yields an alignment field of ".balign 119,0x90", which should
never
Post by J. Gareth Moreton
happen.
Could you set a breakpoint on aggas.pas:721 (the call to doalign) with a
conditional on "tai_align_abstract(hp).aligntype=119" and check what the
actual
type of hp is? It could be that at some point a node gets its typ changed
in an
invalid way?
aligntype should be either one of 2^[0..5], never something else...

This is where AddressSanitizer support would be *nice*.

--
Regards,
Martok

Ceterum censeo b32079 esse sanandam.

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org [1]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[2]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org [3]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[4]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



Links:

Loading...