KSE: whom to blame, -current SMP or firefox?

Joe Marcus Clarke marcus at marcuscom.com
Fri Nov 18 16:41:48 PST 2005


On Fri, 2005-11-18 at 16:11 +0300, Andrey Chernov wrote:
> The problem: I got 100% dead loop at 'install' stage of the 'firefox' 
> port (after ===> Building Chrome's registry... message).
> '/usr/X11R6/lib/firefox/regchrome' is the program that loops (at the end 
> of its task, so kill -9 continues install normally). That is SMP machine.
> 
> If I leave it for, say, 10mins, I start to get lots of 
> calcru: runtime went backwards from 121010657 usec to 120993592 usec for 
> pid 5769 (regchrome)
> on my console.
> 
> The _same_ 'regchrome' binary & libs set runs without problem and exits 
> quickly on another UP machine!!! Both machines are identical recent 
> -current.
> 
> 'ktrace' shows that loop happens in KSE code. Here is relevant piece of 
> 'kdump':
>   ...
>   9152 regchrome NAMI  "/usr/X11R6/lib/firefox/chrome/.reregchrome"
>   9152 regchrome RET   access -1 errno 2 No such file or directory
>   9152 regchrome CALL  write(0x6,0x282b8f8d,0x1)
>   9152 regchrome GIO   fd 6 wrote 1 byte
>        "8"
>   9152 regchrome RET   write 1
>   9152 regchrome CALL  kse_release(0xbfbfe8a0)
>   9152 regchrome RET   kse_release 0
>   9152 regchrome CALL  read(0x5,0xbf8fdb40,0x400)
>   9152 regchrome GIO   fd 5 read 1 byte
>        "8"
>   9152 regchrome RET   read 1
>   9152 regchrome CALL  kse_release(0xbf8fdeb0)
>   9152 regchrome RET   kse_release 0
>   9152 regchrome CALL  kse_release(0xbfbfe8a0)
>   9152 regchrome RET   kse_release 0
>   9152 regchrome CALL  kse_release(0xbf8fdeb0)
>   9152 regchrome RET   kse_release 0
>   9152 regchrome CALL  kse_release(0xbfbfe8a0)
>   9152 regchrome RET   kse_release 0
>   9152 regchrome CALL  kse_release(0xbf8fdeb0)
>   9152 regchrome RET   kse_release 0
>   ... loops ...
> 
> Any ideas?

Could have to do with your CFLAGS.  I certainly don't see this on my
-CURRENT i386 machine using default CFLAGS (plus -g).  That machine is a
single CPU system with Hyperthreading enabled, so it looks like two
CPUs.  However, there may be a true SMP problem, but I don't think it's
anything known to the FreeBSD GNOME team.

Joe

-- 
PGP Key : http://www.marcuscom.com/pgp.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20051118/712b5449/attachment.bin


More information about the freebsd-current mailing list