pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Brian Wipf <brian@clickspace.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@postgresql.org, Guido Neitzer <lists@event-s.net>
Cc: Brendan Duddridge <brendan@clickspace.com>
Cc: Jim C. Nasby <jim@nasby.net>
Subject: Re: shared_buffers > 284263 on OS X
Date: Tue, 5 Dec 2006 17:06:20 -0700
Message-ID: <CC7ED9FE-1188-4102-98AF-21B5BBA97CF6@clickspace.com> (raw)
In-Reply-To: <15563.1165360236@sss.pgh.pa.us>
References: <FFB38162-AF10-452D-AFA1-B964F1E48B34@clickspace.com>
	<15563.1165360236@sss.pgh.pa.us>

On 5-Dec-06, at 4:10 PM, Tom Lane wrote:
> Brian Wipf <brian@clickspace.com> writes:
>> shared_buffers can now be set as high as shmmax without getting the
>> error message "could not create shared memory segment...". Now,
>> however, when shared_buffers are set greater than 279212 a
>> segmentation fault occurs on startup of PostgreSQL.
>
> Stack trace please?

Normally, when something crashes in OS X, I get a stack trace in the / 
Library/Logs/CrashReporter/crashdump.crash.log. Unfortunately, the  
only stack trace in crashdump.crash.log appears to be for  
CrashReporter itself crashing. A guess is that crashreporterd is only  
32-bit and can't handle generating a report for the crash of a 64-bit  
program.

# file /usr/libexec/crashreporterd
/usr/libexec/crashreporterd: Mach-O executable ppc

Running gdb on the only generated core file shows:

/cores root# gdb /usr/local/pgsql/bin/postgres core.708
GNU gdb 6.3.50-20050815 (Apple version gdb-573) (Fri Oct 20 15:54:33  
GMT 2006)
Core was generated by `/usr/libexec/crashdump'.
#0  0x00000000fffeff20 in ?? ()
(gdb) bt
#0  0x00000000fffeff20 in ?? ()
Cannot access memory at address 0xbffffa8000000000
#1  0x000000009293d968 in ?? ()
Cannot access memory at address 0xbffffa8000000000
Cannot access memory at address 0xbffffa8000000010

which appears to be for Crash Reporter crashing. Any idea how I might  
be able to get a useful stack trace?

All crashdump.crash.log shows is:

Host Name:      Hulk1
Date/Time:      2006-12-05 23:36:51.928 +0000
OS Version:     10.4.8 (Build 8L127)
Report Version: 4

Command: crashdump
Path:    /usr/libexec/crashdump
Parent:  crashreporterd [112]

Version: ??? (???)

PID:    708
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x789421ff

Thread 0 Crashed:
0   <<00000000>>        0xfffeff20 objc_msgSend_rtp + 32
1   com.apple.Foundation        0x9293d968 NSPopAutoreleasePool + 536
2   crashdump                   0x00005c58 0x1000 + 19544
3   crashdump                   0x00005cec 0x1000 + 19692
4   crashdump                   0x00002954 0x1000 + 6484
5   crashdump                   0x000027f8 0x1000 + 6136

Thread 0 crashed with PPC Thread State 64:
   srr0: 0x00000000fffeff20 srr1:  
0x100000000000f030                        vrsave: 0x0000000000000000
     cr: 0x44000234          xer: 0x0000000000000000   lr:  
0x000000009293d968  ctr: 0x0000000000000001
     r0: 0x0000000000000001   r1: 0x00000000bffff620   r2:  
0x00000000789421ff   r3: 0x0000000000308bc0
     r4: 0x0000000090aa8904   r5: 0x0000000001800000   r6:  
0xffffffffffffffff   r7: 0x0000000001807400
     r8: 0x0000000000000001   r9: 0x0000000000030000  r10:  
0x0000000000000005  r11: 0x000000006f548904
    r12: 0x000000000000357b  r13: 0x0000000000000000  r14:  
0x0000000000000000  r15: 0x0000000000000000
    r16: 0x0000000000000000  r17: 0x0000000000000000  r18:  
0x0000000000000000  r19: 0x0000000000000000
    r20: 0x0000000000000000  r21: 0x0000000000000000  r22:  
0x0000000000000000  r23: 0x0000000000000000
    r24: 0x0000000000000000  r25: 0x0000000000306990  r26:  
0x0000000000010000  r27: 0x0000000000000001
    r28: 0x0000000000010000  r29: 0x0000000000308bc0  r30:  
0x000000000000d02c  r31: 0x000000009293d764

Binary Images Description:
     0x1000 -     0xbfff crashdump       /usr/libexec/crashdump
0x8fe00000 - 0x8fe51fff dyld 45.3       /usr/lib/dyld
0x90000000 - 0x901bcfff libSystem.B.dylib       /usr/lib/ 
libSystem.B.dylib
0x90214000 - 0x90219fff libmathCommon.A.dylib   /usr/lib/system/ 
libmathCommon.A.dylib
0x9021b000 - 0x90268fff com.apple.CoreText 1.0.2 (???)  /System/ 
Library/Frameworks/ApplicationServices.framework/Versions/A/ 
Frameworks/CoreText.framework/Versions/A/CoreText
...
...
0x94281000 - 0x94281fff com.apple.audio.units.AudioUnit 1.4     / 
System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
0x94283000 - 0x94456fff com.apple.QuartzCore 1.4.9      /System/ 
Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
0x944ac000 - 0x944e9fff libsqlite3.0.dylib      /usr/lib/ 
libsqlite3.0.dylib
0x944f1000 - 0x94541fff libGLImage.dylib        /System/Library/ 
Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
0x945d2000 - 0x94614fff com.apple.vmutils 4.0.2 (93.1)  /System/ 
Library/PrivateFrameworks/vmutils.framework/Versions/A/vmutils





view thread (21+ messages)

Message-ID: <CC7ED9FE-1188-4102-98AF-21B5BBA97CF6@clickspace.com>
Permalink:  ../CC7ED9FE-1188-4102-98AF-21B5BBA97CF6@clickspace.com/
Also on:    postgresql.org/message-id/CC7ED9FE-1188-4102-98AF-21B5BBA97CF6@clickspace.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: brian@clickspace.com, tgl@sss.pgh.pa.us, lists@event-s.net, brendan@clickspace.com, jim@nasby.net
  Subject: Re: shared_buffers > 284263 on OS X
  In-Reply-To: <CC7ED9FE-1188-4102-98AF-21B5BBA97CF6@clickspace.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox