Re: 7.2.1 segfaults.
От | Stephen Amadei |
---|---|
Тема | Re: 7.2.1 segfaults. |
Дата | |
Msg-id | Pine.LNX.4.44.0205032348040.1906-100000@rastaban.dandy.net обсуждение исходный текст |
Ответ на | Re: 7.2.1 segfaults. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: 7.2.1 segfaults.
|
Список | pgsql-bugs |
On Fri, 3 May 2002, Tom Lane wrote: > Stephen Amadei <amadei@dandy.net> writes: > >> Urgh. Can you provide a stack trace? > > > You mean using strace? Yeah. The strace created quite a bit of logs, but > > the process that segfaulted is included below. > > > open("/usr/local/pgsql/data/global/1262", O_RDONLY) = 4 > > read(4, "\0\0\0\0\f\222\20\0\7\0\0\0\34\0\244\37\0 \0 \244\37\0"..., 8192) = 8192 > > --- SIGSEGV (Segmentation fault) --- > > Hmm, this does not square with your prior statement that it's a chroot > can't-call-/bin/cp issue. It's not. I don't mean to confuse the two separate problems, that's why I made two threads. In order to be sure that neither GRSecurity or the chroot was causing the segfault, I disabled these features and ran postmaster as a normal user would... but I still connected via TCPIP. > Would you set things up to allow a core dump > (ie, not ulimit -c 0) and then do "gdb postgres-executable corefile" > followed by "bt"? Uh... sure. This will take a moment. O.K... I think I have the info. #0 0x255843 in strncpy (s1=0xbfffead0 "n\013", s2=0x8213414 "n\013", n=4294967292) at ../sysdeps/generic/strncpy.c:82 #1 0x81516ab in GetRawDatabaseInfo () #2 0x81511fb in InitPostgres () I am not real familiar with gdb, so I only vaguely know what this shows, besides stack. And in the above info, the 'n' in "n\013" actually has a little '~' above it, but I figured that character might get managed by the email. ----Steve Stephen Amadei Dandy.NET! CTO Atlantic City, NJ
В списке pgsql-bugs по дате отправления: