On Tue, Oct 3, 2017 at 8:31 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Tue, Oct 3, 2017 at 3:04 AM, Andreas Seltenreich <seltenre...@gmx.de> > 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 looks >> like it was passed a pointer to gone-away shared memory. >> > > It appears to be some dangling pointer, but not sure how it is > possible. Can you provide some more details, like do you have any > other library which you want to get loaded in the backend (like by > using shared_preload_libraries or by some other way)? I think without > that we shouldn't try to load anything in the parallel worker. >
Another possibility could be that the memory for library space has been overwritten either in master backend or in worker backend. I think that is possible in low-memory conditions if in someplace we try to write in the memory without ensuring if space is allocated. I have browsed the nearby code and didn't find any such instance. One idea to narrow down the problem is to see if the other members in worker backend are sane, for ex. can you try printing the value of MyFixedParallelState as we get that value from shared memory similar to libraryspace. It seems from call stack that the memory of libraryspace is corrupted, so we can move the call to lookup/RestoreLibraryState immediately after we assign MyFixedParallelState. I think if after this also the memory for libraryspace is corrupted, then probably something bad has happened in master backend. Any other ideas? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
