Re: bison-1.35 Compile error on Current
On Sun, Jun 23, 2002 at 12:50:54PM -0700, David O'Brien wrote: > I cannot reproduce either your ports/lang/gcc31 or this problem. > At this point I am suspecting something is wrong with your system. I get the same exact problem with the most recent current. This installation originally came from the April CD of -current. bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
statvfs() undefined ?(linux_base build problems)
Hello, I run into when building linux_base under the most recent -current: gmake[2]: Entering directory `/usr/ports/archivers/rpm/work/rpm-3.0.6/tools' /bin/sh ../libtool --mode=link cc -O -pipe -D_GNU_SOURCE -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wno-char-subscripts -L../build -L../lib -o dump dump.o ../build/librpmbuild.la ../lib/librpm.la-lpopt ../misc/libmisc.a -L/usr/local/lib -lintl -liconv -L/usr/local/lib -lz -lbz2 cc -O -pipe -D_GNU_SOURCE -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wno-char-subscripts -L../build -L../lib -o .libs/dump dump.o ../build/.libs/librpmbuild.so -L/usr/local/lib -lintl -liconv -lz -lbz2 ../lib/.libs/librpm.so -lintl -liconv -lz -lbz2 -lpopt ../misc/libmisc.a -L/usr/local/lib -lintl -liconv -L/usr/local/lib -lz -lbz2 -Wl,--rpath -Wl,/usr/local/lib ../lib/.libs/librpm.so: warning: tempnam() possibly used unsafely; consider using mkstemp() ../lib/.libs/librpm.so: warning: mktemp() possibly used unsafely; consider using mkstemp() ../lib/.libs/librpm.so: undefined reference to `statvfs' gmake[2]: *** [dump] Error 1 gmake[2]: Leaving directory `/usr/ports/archivers/rpm/work/rpm-3.0.6/tools' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/archivers/rpm/work/rpm-3.0.6' gmake: *** [all-recursive-am] Error 2 *** Error code 2 Stop in /usr/ports/archivers/rpm. *** Error code 1 Stop in /usr/ports/emulators/linux_base. Grepping through /usr/src/ didn't reveal that these functions were defined. Are they in an external package or is this broken ? bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE desaster
On Mon, Jul 01, 2002 at 07:11:31AM +0200, Michael Nottebrock wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x281cc918 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.5 > (gdb) bt > #0 0x281cc918 in _thread_kern_sched_state_unlock () from > /usr/lib/libc_r.so.5 > #1 0x281cc2e2 in _thread_kern_scheduler () from /usr/lib/libc_r.so.5 > #2 0xd0d0d0d0 in ?? () > #3 0x080570b0 in ?? () This is unlikely to be a KSE problem. What do the rest of the threads look like ? Try "info threads" in gdb and then progressively walking through the thread list with "thread N", N being the thread number. I ran into a funny create at thread start up time crash and I'm wondering if it could be the same thing. bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
On Mon, Jul 01, 2002 at 02:59:09AM -0400, Wesley Morgan wrote: > 2723 kdeinit CALL gettimeofday(0x28e94ab8,0) > 2723 kdeinit RET gettimeofday 0 > 2723 kdeinit CALL wait4(0x,0,0x1,0) > 2723 kdeinit RET wait4 2724/0xaa4 > 2723 kdeinit CALL poll(0x8059000,0x1,0) > 2723 kdeinit RET poll 1 > 2723 kdeinit PSIG SIGSEGV SIG_DFL > 2723 kdeinit NAMI "kdeinit.core" > > Both the kdeinit and a child it forks are dying... Setting a breakpoint of > fork() in the binary shows: That's almost definitely the same problem I'm running into with the JVM, however it registered itself has an infinite hang since SEGV deliveries are turned off when inside in a crashing/SEGVing libc_r thread-kernel. bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
On Tue, Jul 02, 2002 at 10:53:23PM -0500, Erik Greenwald wrote: > I took a stab at hunting it down, I think I may've found it in the > libc_r, not the kern > > src/lib/libc_r/uthread/uthread_kern.c, in the neighborhood of line 172, > the last line of _thread_kern_sched() is > > ___longjmp(_thread_kern_sched_jb, 1); > > I think that's where the crash is. the setjmp is in uthread_init.c, on > line 320, "_setjmp(_thread_kern_sched_jb);", but that function doesn't > seem to be called? I put some printf's with fflush's in there and I'm > not seeing them come up. Maybe I'm misreading something, but that seems > to me to be the issue, _thread_kern_sched_jb having junk when it gets > longjmp'd... I'm really not quite what all goes into this, so I'm > throwing this out to let more experienced minds consider it? :) I think > I'm going to wait an hour or two before trying to fix it, maybe someone > sees this as a quick fix Yeah, that's where I'm poking at currently. The thing that I'm seeing is that the entry function _thread_start is on the wrong stack. This problem predates the KSE commit, so it's not related to it. It could be that the jump_buf isn't being set up correctly or some other unknown craziness, but I believe I'm close to finding the SEGV in question. The problem is persistent across pre-KSE (3 days ago) and KSE kernels. I'm running an older kernel now with the latest world, so that the environment is stable enough for me to do bug tracking. If I'm doing something wrong, then please tell me. bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Another KSE problem?
On Thu, Jul 11, 2002 at 09:55:51AM -0700, Julian Elischer wrote: > I have no idea what xmms is, but it seems doubtlfu that this is a KSE > problem. Hey, xmms is a very popular audio media player. BTW, I'm getting a lot of orphaned processes when I run a program in gdb and you deliver a SIGQUIT that seem to be stuck in poll(). It's 100 percent repeatable. bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Another KSE problem?
On Thu, Jul 11, 2002 at 06:39:27PM -0700, Bill Huey wrote: > BTW, I'm getting a lot of orphaned processes when I run a program in gdb > and you deliver a SIGQUIT that seem to be stuck in poll(). It's 100 percent > repeatable. Here's a ps axl: = 1001 312 1 0 96 0 116264 5767 - W p10:07.79 /usr/home/billh/javasrc_1_3_scsl/j2sdk1.3.1/build/bsd-i386/bin/i386/native_threads/java -jar 1001 1339 1 0 96 0 116580 5978 - W p10:07.80 /usr/home/billh/javasrc_1_3_scsl/j2sdk1.3.1/build/bsd-i386/bin/i386/native_threads/java -jar = I found that not reporting what state it was in peculiar. bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Another KSE problem?
On Thu, Jul 11, 2002 at 10:58:56PM -0700, Julian Elischer wrote: > it may be in "NEW" state if it has just been forked. > if so then the "NEW" state is hanging around too long. > it should be fixed tomorrow after testing. What do you mean by just forked ? This is a running process that's block on a kernel of some sort within libc_r. If my reading of the problem is correct, then there might be a problem with signal delivery and things like select/poll. I don't know until I do some investigation. bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Another KSE problem?
On Thu, Jul 11, 2002 at 11:42:56PM -0700, Julian Elischer wrote: > I was asking if it was a newly forked process... No, its not. It's something that's been running for at least a few seconds. Sorry to be unclear about that. bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ast() assert failed ?
Hello, I get a billion of these: failed to set signal flags proprly for ast() failed to set signal flags proprly for ast() failed to set signal flags proprly for ast() failed to set signal flags proprly for ast() failed to set signal flags proprly for ast() failed to set signal flags proprly for ast() Is this KSE related ? bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ast() assert failed ?
On Tue, Jul 16, 2002 at 07:04:46AM +1000, Bruce Evans wrote: > Maybe. I got a few of these for my original ast() changes an instant > after I committed them (long before KSEIII), but haven't been able to > duplicate the problem (perhaps because they only occurred for SMP and > I rarely run SMP). I use the following change which prints more info > and fixes a spelling error (*blush*). Hey, Isn't this evil ? Jul 15 14:50:09 finfin kernel: failed to set signal flags properly for ast() Jul 15 14:50:09 finfin kernel: proc java sig 0x400, sigmask 0xfffef007, sigflag 0, astflag 0 Jul 15 14:50:09 finfin kernel: failed to set signal flags properly for ast() Jul 15 14:50:09 finfin kernel: proc java sig 0x400, sigmask 0xfffef007, sigflag 0, astflag 0 It's wierd since all of a sudden this showed up and I think I've been using this kernel for quite a while now (pre-pmap changes). No, wierd pmap problems so far... bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ast() assert failed ?
On Mon, Jul 15, 2002 at 06:00:32PM -0400, Alexander Kabaev wrote: > Bruce, > > I am reliably get these messages while using gdb on user processes. This > started long before KSEIII. Right, I forgot to add that I was also running this program under gdb. I'm using the most recent -current right now. bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
