On Tue, Oct 3, 2017 at 3:04 AM, Andreas Seltenreich wrote:
> Tom Lane writes:
>> Presumably somebody could dig into the libc source code and prove or
>> disprove this, though it would sure help to know exactly what platform
>> and version Andreas is testing on.
>
> This is the
Tom Lane writes:
> Presumably somebody could dig into the libc source code and prove or
> disprove this, though it would sure help to know exactly what platform
> and version Andreas is testing on.
This is the code in glibc-2.24 around the crash site:
,[ glibc-2.24/elf/dl-load.c:442 ]
|
Amit Kapila writes:
> Any other ideas?
Given that the crash is so far down inside __dlopen(), and that there's
a clear reference to the string we presumably passed to that:
#11 0x7f518485e489 in _dl_open (file=0x55b692f2d2b0
On Tue, Oct 3, 2017 at 8:31 AM, Amit Kapila wrote:
> On Tue, Oct 3, 2017 at 3:04 AM, Andreas Seltenreich
> wrote:
>> Hi,
>>
>> doing low-memory testing with REL_10_STABLE at 1f19550a87 also produced
>> a couple of parallel worker core dumps with the
On Tue, Oct 3, 2017 at 3:04 AM, Andreas Seltenreich wrote:
> Hi,
>
> doing low-memory testing with REL_10_STABLE at 1f19550a87 also produced
> a couple of parallel worker core dumps with the backtrace below.
> Although most of the backtrace is inside the dynamic linker, it
Hi,
doing low-memory testing with REL_10_STABLE at 1f19550a87 also produced
a couple of parallel worker core dumps with the backtrace below.
Although most of the backtrace is inside the dynamic linker, it looks
like it was passed a pointer to gone-away shared memory.
regards,
Andreas
Core was