On Mon, Oct 20, 2014 at 10:24:47PM +0200, Andres Freund wrote:
> On 2014-10-20 01:03:31 -0400, Noah Misch wrote:
> > On Wed, Oct 15, 2014 at 12:53:03AM -0400, Noah Misch wrote:
> > I happened to try the same contrib/dblink test suite on PostgreSQL built
> > with
> > modern MinGW-w64 (i686-4.9.1-release-win32-dwarf-rt_v3-rev1). That, too,
> > gave
> > a crash-like symptom starting with commit 846e91e. Specifically, a backend
> > that LOADed any module linked to libpq (libpqwalreceiver, dblink,
> > postgres_fdw) would suffer this after calling exit(0):
> >
> > ===
> > 3056 2014-10-20 00:40:15.163 GMT LOG: disconnection: session time:
> > 0:00:00.515 user=cyg_server database=template1 host=127.0.0.1 port=3936
> >
> > This application has requested the Runtime to terminate it in an unusual
> > way.
> > Please contact the application's support team for more information.
> >
> > This application has requested the Runtime to terminate it in an unusual
> > way.
> > Please contact the application's support team for more information.
> > 9300 2014-10-20 00:40:15.163 GMT LOG: server process (PID 3056) exited
> > with exit code 3
> > ===
> >
> > The mechanism turned out to be disjoint from the mechanism behind the
> > ancient-compiler crash. Based on the functions called from exit(), my best
> > guess is that exit() encountered recursion and used something like an
> > abort()
> > to escape.
>
> Hm.
>
> > (I can send the gdb transcript if anyone is curious to see the
> > gory details.)
>
> That would be interesting.
Attached. ("rep 100 s" calls a macro equivalent to issuing "s" 100 times.)
> > The proximate cause was commit 846e91e allowing modules to use
> > shared libgcc. A 32-bit libpq acquires 64-bit integer division from libgcc.
> > Passing -static-libgcc to the link restores the libgcc situation as it stood
> > before commit 846e91e. The main beneficiary of shared libgcc is C++/Java
> > exception handling, so PostgreSQL doesn't care. No doubt there's some
> > deeper
> > bug in libgcc or in PostgreSQL; loading a module that links with shared
> > libgcc
> > should not disrupt exit(). I'm content with this workaround.
>
> I'm unconvinced by this reasoning. Popular postgres extensions like
> postgis do use C++. It's imo not hard to imagine situations where
> switching to a statically linked libgcc statically could cause problems.
True; I was wrong to say that PostgreSQL doesn't care. MinGW builds of every
released PostgreSQL version use static libgcc. That changed as an unintended
consequence of a patch designed to remove our reliance on dlltool. Given the
lack of complaints about our historic use of static libgcc, I think it's fair
to revert to 9.3's use thereof. Supporting shared libgcc would be better
still, should someone make that effort.
Breakpoint 1, 0x77bcaf46 in msvcrt!exit () from C:\WINDOWS\system32\msvcrt.dll
#0 0x77bcaf46 in msvcrt!exit () from C:\WINDOWS\system32\msvcrt.dll
#1 0x0065637b in proc_exit (code=code@entry=0) at ipc.c:143
#2 0x006798bf in PostgresMain (argc=1, argv=argv@entry=0x225830,
dbname=0x224498 "template1", username=0x224460 "cyg_server")
at postgres.c:4232
#3 0x0061b26e in BackendRun (port=0x205f520) at postmaster.c:4113
#4 SubPostmasterMain (argc=argc@entry=3, argv=argv@entry=0x222e88)
at postmaster.c:4617
#5 0x007af2a1 in main (argc=3, argv=0x222e88) at main.c:196
(gdb) s
Single stepping until exit from function msvcrt!exit,
which has no line number information.
0x77bcae7a in msvcrt!_initterm () from C:\WINDOWS\system32\msvcrt.dll
(gdb)
Single stepping until exit from function msvcrt!_initterm,
which has no line number information.
0x77bc84c4 in strerror () from C:\WINDOWS\system32\msvcrt.dll
(gdb)
Single stepping until exit from function strerror,
which has no line number information.
0x77bcae86 in msvcrt!_initterm () from C:\WINDOWS\system32\msvcrt.dll
(gdb)
Single stepping until exit from function msvcrt!_initterm,
which has no line number information.
atexit_callback () at ipc.c:283
warning: Source file is more recent than executable.
283 proc_exit_prepare(-1);
(gdb)
proc_exit_prepare (code=-1) at ipc.c:153
153 {
(gdb) fin
Run till exit from #0 proc_exit_prepare (code=-1) at ipc.c:153
0x77bcaed6 in msvcrt!_initterm () from C:\WINDOWS\system32\msvcrt.dll
(gdb) s
Single stepping until exit from function msvcrt!_initterm,
which has no line number information.
Breakpoint 1, 0x77bcaf61 in msvcrt!_exit ()
from C:\WINDOWS\system32\msvcrt.dll
(gdb) rep 100 s
Single stepping until exit from function msvcrt!_exit,
which has no line number information.
0x77bcae7a in msvcrt!_initterm () from C:\WINDOWS\system32\msvcrt.dll
Single stepping until exit from function msvcrt!_initterm,
which has no line number information.
0x77bc84c4 in strerror () from C:\WINDOWS\system32\msvcrt.dll
Single stepping until exit from function strerror,
which has no line number information.
0x77bcae86 in msvcrt!_initterm () from C:\WINDOWS\system32\msvcrt.dll
Single stepping until exit from function msvcrt!_initterm,
which has no line number information.
0x77bcadb2 in strerror () from C:\WINDOWS\system32\msvcrt.dll
Single stepping until exit from function strerror,
which has no line number information.
0x77e64770 in KERNEL32!GetModuleHandleA ()
from C:\WINDOWS\system32\kernel32.dll
Single stepping until exit from function KERNEL32!GetModuleHandleA,
which has no line number information.
0x77bcadc2 in strerror () from C:\WINDOWS\system32\msvcrt.dll
Single stepping until exit from function strerror,
which has no line number information.
Breakpoint 1, 0x77bcaf61 in msvcrt!_exit ()
from C:\WINDOWS\system32\msvcrt.dll
Single stepping until exit from function msvcrt!_exit,
which has no line number information.
0x77bcae7a in msvcrt!_initterm () from C:\WINDOWS\system32\msvcrt.dll
Single stepping until exit from function msvcrt!_initterm,
which has no line number information.
0x77bc84c4 in strerror () from C:\WINDOWS\system32\msvcrt.dll
Single stepping until exit from function strerror,
which has no line number information.
[Thread 3896.0x1ed8 exited with code 3]
0x77bcae86 in msvcrt!_initterm () from C:\WINDOWS\system32\msvcrt.dll
Single stepping until exit from function msvcrt!_initterm,
which has no line number information.
0x77bcadb2 in strerror () from C:\WINDOWS\system32\msvcrt.dll
Single stepping until exit from function strerror,
which has no line number information.
0x77e64770 in KERNEL32!GetModuleHandleA ()
from C:\WINDOWS\system32\kernel32.dll
Single stepping until exit from function KERNEL32!GetModuleHandleA,
which has no line number information.
[Thread 3896.0x2c30 exited with code 3]
0x77bcadc2 in strerror () from C:\WINDOWS\system32\msvcrt.dll
Single stepping until exit from function strerror,
which has no line number information.
[Inferior 1 (process 3896) exited with code 03]
The program is not being run.
(gdb)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
