RFR: Fix stacktraces
axel.siebenborn at sap.com
Tue Apr 10 09:17:08 UTC 2018
I sent a patch to the musl list, but there was no reaction until now.
I don't like the workaround using the MUSL macro.
As I understand the code, the part I don't use for musl, is a fast path, that is not really needed.
And there are not many exported symbols in the libjvm, where this path is executed.
I think, it wouldn't hurt to remove it for all linuxes.
> -----Original Message-----
> From: Mikael Vidstedt [mailto:mikael.vidstedt at oracle.com]
> Sent: Montag, 9. April 2018 19:37
> To: Siebenborn, Axel <axel.siebenborn at sap.com>
> Cc: portola-dev at openjdk.java.net
> Subject: Re: RFR: Fix stacktraces
> I’m torn about this one, I don’t really like having to patch around things like
> this, but I don’t have a better suggestion. Question though: do you know if
> the "faulty implementation” is by-design in musl, or if it’s something that
> should be fixed?
> > On Apr 4, 2018, at 7:42 AM, Siebenborn, Axel <axel.siebenborn at sap.com>
> > Hi,
> > Currently, stacktraces are not working correctly in portola. The reason is a
> faulty implementation of dladdr.
> > Due to a missing comparison with the size, dladdr claims to have found a
> symbol for an address, whereas this is just the nearest exported symbol
> lower to that address. Pointing into a function with a non-exported symbol,
> returning NULL for dlinfo.dli_sname and dlinfo.dli_saddr would be the
> expected behavior.
> > The fix is not to use the faulty results of dladdr for dlinfo.dli_sname and
> dlinfo.dli_saddr and to go the slow path,
> > getting the file info using the Decoder class.
> > As most symbols in libjvm are not exported, this is the common case
> > I protected the code with #ifndef LIBMUSL. To get this define, I had to
> change CompileJvm.gmk.
> > Webrev:
> > http://cr.openjdk.java.net/~asiebenborn/stacktraces/webrev/
> > Regards,
> > Axel
More information about the portola-dev