On Fri, Nov 18, 2005 at 12:35:44AM -0500, Michael Gurski wrote: > Apparently I spoke too soon. I'm getting segfaults when I try to > pbuild. Running sks with strace, it seems to bomb out in in mremap, and > a backtrace on the core yields: > > (gdb) where > #0 0x00002aaaaae302a1 in __db_tas_mutex_lock_4001 () from > /usr/lib/libdb-4.1.so > #1 0x00002aaaaaea68a0 in __memp_fget_4001 () from /usr/lib/libdb-4.1.so > #2 0x00002aaaaae3cf73 in __bam_c_dup_4001 () from /usr/lib/libdb-4.1.so > #3 0x00002aaaaae40286 in __bam_c_rget_4001 () from > /usr/lib/libdb-4.1.so > #4 0x00002aaaaae5f276 in __db_c_get_4001 () from /usr/lib/libdb-4.1.so > #5 0x00000000004d8e2a in bzero () > #6 0x00000000004ed5cc in bzero () > > I've been googling for berkeley db4.1 problems, but haven't been able to > find anything. Has anyone seen this before on an AMD64?
Nevermind, I found it. Out of desperation, I started mucking with various ulimit settings to see if they had any effect. As most were already "unlimited", I had open files, pipe size, and stack size to choose from. Apparently what was happening was sks was blowing its stack, as doubling the stacksize limit (from 8192 to 16384) allowed pbuild to run to completion without any problems. So, uh, yay desperation? -- Michael A. Gurski (opt. [first].)[EMAIL PROTECTED] http://www.pobox.com/~[last] 1024R/39B5BADD PGP: 34 93 A9 94 B1 59 48 B7 17 57 1E 4E 62 56 45 70 1024D/1166213E GPG: 628F 37A4 62AF 1475 45DB AD81 ADC9 E606 1166 213E 4096R/C0B4F04B GPG: 5B3E 75D7 43CF CF34 4042 7788 1DCE B5EE C0B4 F04B Views expressed by the host do not reflect the staff, management or sponsors. "The ideas which now pass for brilliant innovations and advances are in fact mere revivals of ancient errors, and a further proof of the dictum that those who are ignorant of the past are condemned to repeat it." --Henry Hazlitt
signature.asc
Description: Digital signature
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
