Hi Faidon
On Wed, Feb 17, 2021 at 02:01:20AM +0200, Faidon Liambotis wrote:
> Hi Andreas,
>
> On Wed, Feb 10, 2021 at 01:09:30PM +0100, Andreas Tille wrote:
> > I tried to fix the test issues of drmaa. Besides a missing Depends
> > which was fixed in Git[1] this bug of jmalloc2 affects the import:
> > [...]
> > So for drmaa it is release critical to fix the issue.
>
> I'm sorry to hear that -- that doesn't sound great indeed!
>
> The issue here seems to be that we have to choose between those two
> options:
>
> * Crashes such as the one you experience, effectively happening when
> one tries to dlopen() a library that is linked with jemalloc
> (libdrmaa), from a binary that is not linked with jemalloc (Python).
> This is what we have now.
>
> * Building jemalloc with --disable-initial-exec-tls, which would allow
> dynamically loading jemalloc, but which will result into two malloc
> implementations (glibc's and jemalloc's) to coexist in the same
> process. In this case, if -for whatever reason- a pointer leaks from
> one implementation to the other (though e.g. a realloc call, free
> etc.), we would see some really weird and confusing crashes or
> deadlocks.
>
> None of the two are great options! I don't feel super comfortable to
> make this choice in isolation, so as promised before, I reached out to
> upstream via Gitter¹. Upstream's recommendation is to avoid shipping with
> --disable-initial-exec-tls and continue building the way we are right
> now. Furthermore, they recommend that shared libraries should not define
> their own malloc independent of the process malloc, if they want to use
> the symbol name malloc, and thus should not link with jemalloc (at least
> in the way they currently do). Effectively, they consider this a bug in
> libdrmaa and others like it.
Thanks for the detailed explanation. I need to admit I just stumbled
upon libdrmaa since the package is in Debian Med team scope and the
actual Uploaders did not found sufficient time to care for this issue.
I've never dived into the details of this lib neither do I intend to
to this in future. I just was trying to clarify the situation.
> From a Debian packaging PoV, a) I trust their judgement in evaluating
> this tricky trade-off b) I think it's too late in the bullseye cycle to
> be considering such a high-risk change that could result in weird to
> debug crashes or deadlocks. Let me know if you disagree!
I perfectly agree with you to follow the judgement of upstream and I
absolutely agree with you that this is not the time to fiddle around
with such issues. May be there is an alternative way to fix drmaa.
I think it makes sense if you mark the current bug "wontfix" for the
reasons you gave here to flag the current state.
> I realize this probably not the news you were hoping for. I welcome
> your thoughts and further discussion here, so not marking this as
> wontfix/resolved yet. Hope this helps!
Yes, it definitely helps. As I wrote above I consider wontfix the most
sensible flag.
Kind regards
Andreas.
> 1: https://gitter.im/jemalloc/jemalloc?at=602a62a49ba13e72e42f0ba5
--
http://fam-tille.de
