Re: overwriting an existing .so while being used crashes the server process

From: Tomas Vondra <tv(at)fuzzy(dot)cz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: overwriting an existing .so while being used crashes the server process
Date: 2012-05-30 21:43:35
Message-ID: 4FC69487.7000106@fuzzy.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 30.5.2012 23:19, Tom Lane wrote:
> I suspect it depends on how you install the new version of the library,
> too. I would somewhat expect it to work as you're thinking if the
> install consists of "rename old file out of the way, copy new file into
> place, unlink old file" or equivalent. If you are actually
> *overwriting* the file in place, a crash does not seem especially
> surprising --- it would make perfect sense if the kernel expects the
> file to be usable as backing store for the in-memory image, which is not
> exactly unreasonable. IOW, if the in-memory bits we're executing are
> just an mmap'd image of the .so file, changing the .so file could
> entirely be expected to lead to a crash.

Aha! That might be the culprit - I've just tested that deleting the olf
file and copying new version (thus not overwriting it) did not cause a
crash. Funny.

>> http://www.postgresql.org/docs/9.1/interactive/xfunc-c.html
>
>> After it is used for the first time, a dynamically loaded object
>> file is retained in memory. Future calls in the same session to the
>> function(s) in that file will only incur the small overhead of a
>> symbol table lookup. If you need to force a reload of an object
>> file, for example after recompiling it, begin a fresh session.
>
>> Which kinda looks like my expectation that the session won't crash was
>> correct. Clearly seems like bug to me.
>
> No, that just means that we don't unload it from memory. Where the bits
> actually are, and whether the kernel has defenses against somebody
> modifying the executable, is not something you should be asking us.
> Talk to a kernel hacker for your platform.

OK, thanks for the explanation.

I still think it's worth mentioning this issue in the docs ...

Tomas

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message postgresuser 2012-05-31 00:24:49 BUG #6668: hashjoin cost problem
Previous Message Tom Lane 2012-05-30 21:37:05 Re: pg_dump/pg_restore with time zone displacement out of range