malloc problems in -current malloc_usable_size()

[Mark Atkinson]

Hi,

I updated my kernel/world yesterday and thunderbird 3.0.2 started core
dumping after I completed the upgrade.   It continued to do so on
previously good operations after a full re-compile.

I noticed that some jemalloc changes went in and was wondering if anyone
else was noticing SEGV problems in other apps with malloc_usable_size()
or ARENA problems in threaded apps?

0x28eacb14 in malloc_usable_size () from /lib/libc.so.7


(gdb) bt


#0  0x28eacb14 in malloc_usable_size () from /lib/libc.so.7


#1  0x28eadbaa in free () from /lib/libc.so.7


#2  0x2ed9ac22 in gss_release_buffer () from /usr/lib/libgssapi.so.10


#3  0x2ed9a5ea in gss_release_name () from /usr/lib/libgssapi.so.10


#4  0x2ed96ec9 in gss_init_sec_context () from /usr/lib/libgssapi.so.10


#5  0x2ec0aab4 in NSGetModule () from
/usr/local/lib/thunderbird-3.0.2/components/libauth.so

#6  0x2ec0b5c1 in NSGetModule () from
/usr/local/lib/thunderbird-3.0.2/components/libauth.so

#7  0x291853ea in nsMsgProtocol::AsyncOpen () from
/usr/local/lib/thunderbird-3.0.2/components/libmail.so

#8  0x29255b30 in nsStopwatch::QueryInterface () from
/usr/local/lib/thunderbird-3.0.2/components/libmail.so

#9  0x29255dc5 in nsStopwatch::QueryInterface () from
/usr/local/lib/thunderbird-3.0.2/components/libmail.so
#10 0x291832ee in nsMsgProtocol::OnDataAvailable () from
/usr/local/lib/thunderbird-3.0.2/components/libmail.so
#11 0x2986ff02 in NSGetModule () from
/usr/local/lib/thunderbird-3.0.2/components/libnecko.so
#12 0x298700b6 in NSGetModule () from
/usr/local/lib/thunderbird-3.0.2/components/libnecko.so
#13 0x281f8844 in NS_AsyncCopy () from
/usr/local/lib/thunderbird-3.0.2/libxpcom_core.so
#14 0x28212846 in NS_SetGlobalThreadObserver () from
/usr/local/lib/thunderbird-3.0.2/libxpcom_core.so
#15 0x281d3b7f in NS_ProcessNextEvent_P () from
/usr/local/lib/thunderbird-3.0.2/libxpcom_core.so
#16 0x29a54281 in NSGetModule () from
/usr/local/lib/thunderbird-3.0.2/components/libwidget_gtk2.so
#17 0x29ba1687 in NSGetModule () from
/usr/local/lib/thunderbird-3.0.2/components/libtoolkitcomps.so
#18 0x2819967d in XRE_main () from
/usr/local/lib/thunderbird-3.0.2/libxul.so

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: malloc problems in -current malloc_usable_size()

[Mark Atkinson]

On 03/02/10 09:03, John Baldwin wrote:
> On Tuesday 02 March 2010 11:38:57 am Mark Atkinson wrote:
>> Hi,
>>
>> I updated my kernel/world yesterday and thunderbird 3.0.2 started core
>> dumping after I completed the upgrade.   It continued to do so on
>> previously good operations after a full re-compile.
>>
>> I noticed that some jemalloc changes went in and was wondering if anyone
>> else was noticing SEGV problems in other apps with malloc_usable_size()
>> or ARENA problems in threaded apps?
> 
> This may be a bug in gssapi rather than malloc().  Someone else was reporting 
> segfaults from gss_release_buffer() because it was free()ing a bad pointer
> when using gssapi_krb5.
> 

Thanks for that tip, I didn't associated that with the LDAP thread until
now.   LD_PRELOAD ing a dummy gss_release_buffer() stops the
segfaulting.   Curious it only showed up after I updated.  I had an Jan
11th kernel/world earlier.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: malloc problems in -current malloc_usable_size()

[Mark Atkinson]

On 03/02/10 09:21, Mark Atkinson wrote:
> On 03/02/10 09:03, John Baldwin wrote:
>> On Tuesday 02 March 2010 11:38:57 am Mark Atkinson wrote:
>>> Hi,
>>>
>>> I updated my kernel/world yesterday and thunderbird 3.0.2 started core
>>> dumping after I completed the upgrade.   It continued to do so on
>>> previously good operations after a full re-compile.
>>>
>>> I noticed that some jemalloc changes went in and was wondering if anyone
>>> else was noticing SEGV problems in other apps with malloc_usable_size()
>>> or ARENA problems in threaded apps?
>>
>> This may be a bug in gssapi rather than malloc().  Someone else was 
>> reporting 
>> segfaults from gss_release_buffer() because it was free()ing a bad pointer
>> when using gssapi_krb5.
>>
> 
> Thanks for that tip, I didn't associated that with the LDAP thread until
> now.   LD_PRELOAD ing a dummy gss_release_buffer() stops the
> segfaulting.   Curious it only showed up after I updated.  I had an Jan
> 11th kernel/world earlier.

Just a quick note,

I found that using sasl 2 will also avoid the problem

cyrus-sasl-2.1.23   RFC  SASL (Simple Authentication and Security Layer)

LD_PRELOAD=/usr/local/lib/sasl2/libgssapiv2.so.2 thunderbird


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: wchar.h?

[Mark Atkinson]

On Tue, 9 Mar 1999, Archie Cobbs wrote:
> The jikes Java compiler relies on an include file "whcar.h" being
> on the system. However, even if it's not, it includes routines
> to do what it needs... only about 40 lines or so for these functions:

I was bitten by this one recently too, and there are quite a few messages
in the mailing-list archives on the subject.  If I remember right
(without looking right now) the reason it hasn't been included was some 
sort of issue of 16bit vs 32bit.

The short answer is you need write your own functions and header file that
you need, or use the Xwchar library that came in the original 
X11R5/contrib distributions (with slight modifications to the header file
to use FreeBSD's wchar_t type and specific includes).  It looks like jikes
does the 'right thing' just because there's not that much consistancy
across platforms.

Just FYI HP, linux, and solaris all include a wchar.h, but different
systems are missing different wcs* type functions.

---
Mark Atkinson
Checkpoint Technologies' Metaip Group
ma...@metaip.checkpoint.com
!(wired)?(coffee++):(wired)



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: timer selection w/ one shot timer prevents HP DL385G5 from booting (was usb 3.0)

[Mark Atkinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/06/2010 08:04, Mark Atkinson wrote:
>>> On 10/05/2010 11:39, Mark Atkinson wrote:
> kern.eventtimer.periodic: 0

*sigh* Although I misspelled eventtimer as 'eventtimers' in loader.conf
it still fails to boot without manually selecting the timer.

It's also annoying since '~ ^b' fails to break when it hangs, but '~ ^r'
will work if I give it twice with ALT_BREAK_TO_DEBUGGER.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyslRAACgkQrDN5kXnx8ybMzQCfbLwSk+W7RDmkBnzT4pgsc3oT
I3oAnRMsbPJ1suKgeQ4zJ9M3nw3vM/Jp
=GR7T
-END PGP SIGNATURE-

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Setting up IPv6 in /etc/rc.conf

[Mark Atkinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/15/2010 11:04, Mark Murray wrote:
> Hi
> 
> IPv6 gurus: what are the CURRENT /etc/rc.conf incantations to do the
> following (which works):
> 
> $ ifconfig gif0 create
> $ ifconfig gif0 tunnel 192.168.0.2 11.22.33.44
> $ ifconfig gif0 inet6 2001:::::2 2001:::::1 prefixlen 
> 128
> $ route -n add -inet6 default 2001:::::1
> $ ifconfig gif0 up
> 
> ... when my non-working setup in /etc/rc.conf contains
> 
> gif_interfaces="gif0"
> gifconfig_gif0="192.168.0.2 11.22.33.44"
> gifconfig_gif0_ipv6="2001:::::2 2001:::::1 prefixlen 
> 128"
> ipv6_defaultrouter="-inet6 default 2001:::::1"
> 
> ... which used to work. The bit that fails is the bit where gif0 gets
> its tunnel IPv6 addresses.  I've tried both gifconfig_gif0_ipv6="..."
> and ifconfig_gif0_ipv6="...". The IPv6 endmpoints never make it onto
> gif0.
> 
> This used to work, but setting up IPv6 in CURRENT is a moving
> target, and I can't find a working example any more. I've looked in
> /etc/defaults/rc.conf, but the gifN examples there are all devoid of any
> IPv6 examples.

I found that my ipv6 tunnel setup needed to be dead last in startup.  I
could not get it to configure properly via rc.conf and come up.   So I
just  setup the following script to run after the system comes up (using
your ip examples):

/etc/rc.d/rtadvd stop
ifconfig gif0 inet6  2002001:::::2 2001:::::1
prefixlen 128
ifconfig gif0 inet6 -ifdisabled
route add -inet6 default 2001:::::1
ifconfig internal inet6  2001:::::/64 eui64
ifconfig internal inet6 -ifdisabled
/etc/rc.d/rtadvd start
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAky4nTMACgkQrDN5kXnx8yYbSwCgl34QIrmZwCVF+em+ZoeJPOi0
S/cAnAzmCVxrsoiubNWEW8QWcR1dRlBN
=rM+v
-END PGP SIGNATURE-

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

exclusive sleep mutex mskc0 (network driver) r = 0 (0xc32c3690) locked @ /usr/src/sys/dev/msk/if_msk.c:3589

[Mark Atkinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I updated to current yesterday and got the following 'witness_warn'
panic upon executing 'reboot':

suspending ithread with the following locks held:
exclusive sleep mutex mskc0 (network driver) r = 0 (0xc32c3690) locked @
/usr/src/sys/dev/msk/if_msk.c:3589
panic: witness_warn
cpuid = 0
KDB: enter: panic
Physical memory: 495 MB
Dumping 80 MB: 65 49 33 17 1


   3579 static void
   3580 msk_intr(void *xsc)
   3581 {
   3582 struct msk_softc *sc;
   3583 struct msk_if_softc *sc_if0, *sc_if1;
   3584 struct ifnet *ifp0, *ifp1;
   3585 uint32_t status;
   3586 int domore;
   3587
   3588 sc = xsc;
   3589 MSK_LOCK(sc);
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkve11QACgkQrDN5kXnx8yZQ3wCeJHhG18+7uP0dr3rTsioaCQ4X
sw4AoICW3RKrMdO8q20GIhcT/GglUnWZ
=Az4t
-END PGP SIGNATURE-

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Unable to establish HE gif0 tunnel

[Mark Atkinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I updated a border gateway yesterday from a Feb 23 kernel to a May 2
version kernel/world, and lost my connectivity to my gif0 HE tunnel.

I've been using the following in /etc/rc.conf successfully for some time
to establish the tunnel:

# Hurricane Electric v6 tunnel
ipv6_enable="YES"
gif_interfaces="gif0"
gifconfig_gif0="[MY V4 ADDRESS] [HE V4 ADDRESS]"
ifconfig_gif0="inet6 [MY V6 ENDPOINT] [HE V6 ENDPOINT] prefixlen 128"
ipv6_defaultrouter="[HE V6 ENDPOINT]"

# v6 gateway
ipv6_gateway_enable="YES"
ipv6_network_interfaces="internal"
ipv6_prefix_internal="[MY V6 /64 prefix]
rtadvd_interfaces="internal"

Two problems:

* That seems to configure the tunnel, but it appears as 'tentative'.
* the v6 EUI64 address on interface internal is not assigned as before

gif0: flags=8051 metric 0 mtu 1280
tunnel inet [MY V4 ADDRESS --> [HE V4 ADDRESS]
inet6 fe80::211:2fff:fe46:6347%gif0 prefixlen 64 tentative
scopeid 0x8
inet6 [MY V6 ENDPOINT] --> [HE V6 ENDPOINT] prefixlen 128 tentative
nd6 options=29
options=1

connectivity to HE's v4 endpoint is fine, but I get nada for my own
addresses:
$ ping6 2001:470:a:bd::2
PING6(56=40+8+8 bytes) fe80::202:b3ff:fe97:59f%internal --> 2001:470:a:bd::2
^C
- --- 2001:470:a:bd::2 ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

[r...@hellfire src]$ ping6 2001:470:a:bd::1
ping6: UDP connect: Can't assign requested address

Destroying and recreating gif0 manually has no effect -- same results.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkve2qAACgkQrDN5kXnx8yYfEQCfcbdK/RHygYkPswnUqJ6tS8/Y
v28Ani+9YC2LTLQKkJvXEmC4dOEQBHQp
=zAHG
-END PGP SIGNATURE-

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: SUJ deadlock

[Mark Atkinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/03/10 12:38, Fabien Thomas wrote:
> Hi Jeff,
> 
> I'm with r207548 now and since some days i've system deadlock.
> It seems related to SUJ with process waiting on suspfs or ppwait.

I've also seen it stalled in suspfs, but this information is way better
than what I was able to garner.   I was only able to tell via ctrl-t on
a stalled 'ls' process in a terminal before hard booting.

Right now it occurs everytime I attempt to do the portmaster -a upgrade
of X/KDE on this system.

> The backtrace is the following:
> (kgdb) bt
> #0  sched_switch (td=0xc52d84c0, newtd=0xc4d88980, flags=260) at 
> /usr/home/fabient/fabient-sandbox/sys/kern/sched_ule.c:1853
> #1  0xc0a2838e in mi_switch (flags=260, newtd=0x0) at 
> /usr/home/fabient/fabient-sandbox/sys/kern/kern_synch.c:449
> #2  0xc0a62a25 in sleepq_switch (wchan=0xc5389cf0, pri=159)
> at /usr/home/fabient/fabient-sandbox/sys/kern/subr_sleepqueue.c:530
> #3  0xc0a62c6c in sleepq_wait (wchan=0xc5389cf0, pri=159) at 
> /usr/home/fabient/fabient-sandbox/sys/kern/subr_sleepqueue.c:609
> #4  0xc0a27aec in _sleep (ident=0xc5389cf0, lock=0xc5389ca8, priority=159, 
> wmesg=0xc0f5c302 "suspfs", timo=0)
> at /usr/home/fabient/fabient-sandbox/sys/kern/kern_synch.c:234
> #5  0xc0ae2e62 in vn_start_write (vp=0xc66bdcc0, mpp=0xce79bb6c, flags=1)
> at /usr/home/fabient/fabient-sandbox/sys/kern/vfs_vnops.c:998
> #6  0xc0ae1476 in vn_close (vp=0xc66bdcc0, flags=1, file_cred=0xc577f400, 
> td=0xc52d84c0)
> at /usr/home/fabient/fabient-sandbox/sys/kern/vfs_vnops.c:299
> #7  0xc0ae2cc6 in vn_closefile (fp=0xc7bcd460, td=0xc52d84c0) at 
> /usr/home/fabient/fabient-sandbox/sys/kern/vfs_vnops.c:941
> #8  0xc09d7e5e in fo_close (fp=0xc7bcd460, td=0xc52d84c0) at file.h:270
> #9  0xc09d7ddc in _fdrop (fp=0xc7bcd460, td=0xc52d84c0) at 
> /usr/home/fabient/fabient-sandbox/sys/kern/kern_descrip.c:2348
> #10 0xc09d775b in closef (fp=0xc7bcd460, td=0xc52d84c0) at 
> /usr/home/fabient/fabient-sandbox/sys/kern/kern_descrip.c:2117
> #11 0xc09d526a in kern_close (td=0xc52d84c0, fd=3) at 
> /usr/home/fabient/fabient-sandbox/sys/kern/kern_descrip.c:1162
> #12 0xc09d50ea in close (td=0xc52d84c0, uap=0xce79bcf0) at 
> /usr/home/fabient/fabient-sandbox/sys/kern/kern_descrip.c:1114
> #13 0xc0e5816b in syscall (frame=0xce79bd38) at 
> /usr/home/fabient/fabient-sandbox/sys/i386/i386/trap.c:1116
> #14 0xc0e302e0 in Xint0x80_syscall () at 
> /usr/home/fabient/fabient-sandbox/sys/i386/i386/exception.s:261
> 
> If you need more information tell me.
> 
> Fabien___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvfKk0ACgkQrDN5kXnx8yYpZgCeKRqenQbflLhoa3hVaXP7wICE
9KAAn2HEWuNwgI9EUxA5BYMR6DD0NBgi
=bhDN
-END PGP SIGNATURE-

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: exclusive sleep mutex mskc0 (network driver) r = 0 (0xc32c3690) locked @ /usr/src/sys/dev/msk/if_msk.c:3589

[Mark Atkinson]

On 5/3/2010 12:55 PM, Pyun YongHyeon wrote:
> On Mon, May 03, 2010 at 07:01:56AM -0700, Mark Atkinson wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> I updated to current yesterday and got the following 'witness_warn'
>> panic upon executing 'reboot':
>>
>> suspending ithread with the following locks held:
>> exclusive sleep mutex mskc0 (network driver) r = 0 (0xc32c3690) locked @
>> /usr/src/sys/dev/msk/if_msk.c:3589
>> panic: witness_warn
> 
> It seems msk(4) didn't honor IFF_DRV_RUNNING in status block update
> check so it continued to process received packets.
> Would you try attached patch?

Now it now longer panics, but the system does hang indefinitely.  The
hang occurs at the same time the panic does, which is after disks are
synced right after the 'rebooting' message.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Unable to establish HE gif0 tunnel

[Mark Atkinson]

On 5/3/2010 1:33 PM, Chris Ruiz wrote:
> On Mon, May 3, 2010 at 9:16 AM, Mark Atkinson  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> I updated a border gateway yesterday from a Feb 23 kernel to a May 2
>> version kernel/world, and lost my connectivity to my gif0 HE tunnel.
>>
>> I've been using the following in /etc/rc.conf successfully for some time
>> to establish the tunnel:
> 
>> ifconfig_gif0="inet6 [MY V6 ENDPOINT] [HE V6 ENDPOINT] prefixlen 128"
> 
> There's your problem, bad syntax.  Change it to this:
> 
> ifconfig_gif0_ipv6="inet6 [MY V6 ENDPOINT] [HE V6 ENDPOINT] prefixlen 128"

OK I finally got this to work, however, I cannot boot to single user,
and then 'exit' to mutli-user and have it work.  I'm not sure what's
broken there.

Also, I'm still having a problem with 'tentative'.   For example I
assigned the internal interface with my prefix manually:

ifconfig internal inet6 [prefix]/64 eui64

'tentative' is supposed to disappear after DAD, but instead 'hangs on'
indefinitely.  There appears to be a bug there.  There is no collision
unless it's seeing it's own broadcast somehow.  Even if it did, there's
no log/complaining.

If I set dad count to 0 and remove and re-add the address, still stuck.






___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Unable to establish HE gif0 tunnel

[Mark Atkinson]

On 5/3/2010 6:23 PM, Mark Atkinson wrote:
> On 5/3/2010 1:33 PM, Chris Ruiz wrote:
>> On Mon, May 3, 2010 at 9:16 AM, Mark Atkinson  wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> I updated a border gateway yesterday from a Feb 23 kernel to a May 2
>>> version kernel/world, and lost my connectivity to my gif0 HE tunnel.
>>>
>>> I've been using the following in /etc/rc.conf successfully for some time
>>> to establish the tunnel:
>>
>>> ifconfig_gif0="inet6 [MY V6 ENDPOINT] [HE V6 ENDPOINT] prefixlen 128"
>>
>> There's your problem, bad syntax.  Change it to this:
>>
>> ifconfig_gif0_ipv6="inet6 [MY V6 ENDPOINT] [HE V6 ENDPOINT] prefixlen 128"
> 
> OK I finally got this to work, however, I cannot boot to single user,
> and then 'exit' to mutli-user and have it work.  I'm not sure what's
> broken there.
> 
> Also, I'm still having a problem with 'tentative'.   For example I
> assigned the internal interface with my prefix manually:
> 
> ifconfig internal inet6 [prefix]/64 eui64
> 
> 'tentative' is supposed to disappear after DAD, but instead 'hangs on'
> indefinitely.  There appears to be a bug there.  There is no collision
> unless it's seeing it's own broadcast somehow.  Even if it did, there's
> no log/complaining.
> 
> If I set dad count to 0 and remove and re-add the address, still stuck.

OK, I apparently I have to enable nd6 with -ifenabled.  Somehow I missed
that this became the default along the way.



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

strange svnsync mirror problem.

[Mark Atkinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I had problems building world this morning, and noticed the following
error had occurred that caused svn update to exit:

$ svn update
svn: No such revision 207561

I keep a local svn mirror to update all my clients to, but I couldn't
grab this revision from the repo:

$ svnsync copy-revprops file:///usr/svnmirror/base 207561
svnsync: No such revision 207561

I can't seem to work around this error, other than diving into
the repo and doing updates on directories that avoid revision 207561
(head/lib/libpam/modules/pam_krb5/pam_krb5.8)

Trying to do that found other inconsistencies:

svn: No such revision 207554

any suggestions appreciated.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvi6acACgkQrDN5kXnx8yaz3wCgipcByAgTnL+dBytiKEmaroCk
tjEAoILtV3ySPfEw5O7Y4El2mRVHzeri
=N0Zq
-END PGP SIGNATURE-

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: strange svnsync mirror problem.

[Mark Atkinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/06/10 09:09, Mark Atkinson wrote:
> I had problems building world this morning, and noticed the following
> error had occurred that caused svn update to exit:
> 
> $ svn update
> svn: No such revision 207561
> 
> I keep a local svn mirror to update all my clients to, but I couldn't
> grab this revision from the repo:
> 
> $ svnsync copy-revprops file:///usr/svnmirror/base 207561
> svnsync: No such revision 207561
> 
> I can't seem to work around this error, other than diving into
> the repo and doing updates on directories that avoid revision 207561
> (head/lib/libpam/modules/pam_krb5/pam_krb5.8)
> 
> Trying to do that found other inconsistencies:
> 
> svn: No such revision 207554
> 
> any suggestions appreciated.

Turns out to be corruption of my mirror.  Restored my backup from a few
months ago and resynced.  Not sure how it got there, but I'll be making
more frequent backups of it now.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvjHLIACgkQrDN5kXnx8yZ8igCgg7Do0bJzQ8YNEzhXl37SbDDD
iz0An0jCXv+vE7FoXLB7yYeEtQgAlaBv
=C0Gd
-END PGP SIGNATURE-

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

problems with threads/destructors in -current with llvm/clang

[Mark Atkinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Short backstory, I had recently upgraded my workstation to the latest
current which included clang as default cc now.

Compiling chromium failed for want of SSE2, which led me to recompile
world with CPUTYPE?=core2.   The original flag for world/ports was
CPUTYPE?=i686.

After recompilation chromium would sigbus on loading any extensions.

I made a concerted effort to recompile the whole ports tree and base
on clang to make sure the link stages were CPUTYPE clean, but I
experienced the same behavior.

Probably the best illustration of the type of problems I'm seeing is
qdbus from /usr/ports/devel/dbus-qt4.

Compiled with clang at r243950:

qdbus under kde segfaults in malloc with a huge recursion stack:

[...]
#44740 0x282f7bd4 in QObject::QObject () from
/usr/local/lib/qt4/libQtCore.so.4
#44741 0x281cb649 in QAdoptedThread::QAdoptedThread () from
/usr/local/lib/qt4/libQtCore.so.4
#44742 0x281ce146 in QThreadData::current () from
/usr/local/lib/qt4/libQtCore.so.4
#44743 0x282f7bd4 in QObject::QObject () from
/usr/local/lib/qt4/libQtCore.so.4
#44744 0x281cb649 in QAdoptedThread::QAdoptedThread () from
/usr/local/lib/qt4/libQtCore.so.4
#44745 0x281ce146 in QThreadData::current () from
/usr/local/lib/qt4/libQtCore.so.4
#44746 0x282f7bd4 in QObject::QObject () from
/usr/local/lib/qt4/libQtCore.so.4
#44747 0x281cb649 in QAdoptedThread::QAdoptedThread () from
/usr/local/lib/qt4/libQtCore.so.4
#44748 0x281ce146 in QThreadData::current () from
/usr/local/lib/qt4/libQtCore.so.4
#44749 0x281cbc05 in QThread::currentThread () from
/usr/local/lib/qt4/libQtCore.so.4
#44750 0x28095d21 in QDBusConnectionPrivate::deleteYourself () from
/usr/local/lib/qt4/libQtDBus.so.4
#44751 0x28089634 in QDBusConnection::~QDBusConnection () from
/usr/local/lib/qt4/libQtDBus.so.4
#44752 0x0804b800 in __dtor__ZL10connection ()
#44753 0x28660417 in __cxa_finalize () from /lib/libc.so.7
#44754 0x2860747a in exit () from /lib/libc.so.7
#44755 0x0804c125 in main ()
(gdb)


Compiled with gcc46, no segfault, and seems to follow  a normal
chain to exiting.

[Switching to Thread 29003080 (LWP 100603/qdbus)]

Breakpoint 2, 0x285f8462 in exit () from /lib/libc.so.7
(gdb) n
Single stepping until exit from function exit,
which has no line number information.
0x28677fc0 in f_prealloc () from /lib/libc.so.7
(gdb) n
Single stepping until exit from function f_prealloc,
which has no line number information.
0x2861bd30 in register_printf_render_std () from /lib/libc.so.7
(gdb) n
Single stepping until exit from function register_printf_render_std,
which has no line number information.
0x28678190 in fflush () from /lib/libc.so.7
(gdb) n
Single stepping until exit from function fflush,
which has no line number information.
0x2861bd7e in register_printf_render_std () from /lib/libc.so.7
(gdb) n
Single stepping until exit from function register_printf_render_std,
which has no line number information.
0x28678190 in fflush () from /lib/libc.so.7
(gdb) n
Single stepping until exit from function fflush,
which has no line number information.
0x2861bd7e in register_printf_render_std () from /lib/libc.so.7
(gdb) n
Single stepping until exit from function register_printf_render_std,
which has no line number information.
0x28678190 in fflush () from /lib/libc.so.7
(gdb) n
Single stepping until exit from function fflush,
which has no line number information.
0x2861bd7e in register_printf_render_std () from /lib/libc.so.7
(gdb) n
Single stepping until exit from function register_printf_render_std,
which has no line number information.
0x28677fdf in f_prealloc () from /lib/libc.so.7
(gdb) n
Single stepping until exit from function f_prealloc,
which has no line number information.
0x285f848b in exit () from /lib/libc.so.7
(gdb) n
Single stepping until exit from function exit,
which has no line number information.

Program exited normally.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDA0hcACgkQrDN5kXnx8yb/UACfbpACSvjZGIl7d7H30mb6dptX
C2MAn2Jxfr/9MVKG4HzC1KOBl+N8EiLe
=9pw6
-END PGP SIGNATURE-

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: problems with threads/destructors in -current with llvm/clang

[Mark Atkinson]

On 12/7/2012 6:08 AM, Dimitry Andric wrote:
> On 2012-12-07 13:59, Dimitry Andric wrote:
>> On 2012-12-06 18:12, Mark Atkinson wrote:
>>> Short backstory, I had recently upgraded my workstation to the latest
>>> current which included clang as default cc now.
>> ...
>>> qdbus under kde segfaults in malloc with a huge recursion stack:
> ...
>> This is a bug in qdbus; it uses a global static QDBusConnection object,
>> and the order in which global destructors are called is undefined:
> ...
>> The global static QDBusConnection object should be replaced by a
>> singleton, as suggested here:
> 
> Here is an alternative solution, where the QDBusConnection object is
> just a local variable in main(), and passed around as a const reference.
> To make the destructors work properly, I also replaced the exit() calls
> in main() with return statements.
> 
> With this patch (placed in /usr/ports/devel/dbus-qt4/files), qdbus
> starts up and exits normally for me.  I did not do any other rigorous
> testing, though. :)

Thanks for the awesome analysis.  I will endeavor to figure out the bug
in automoc4 that keeps it segfaulting randomly during compilation.

Weirdly it segfaults reliably under portmaster, but may work just fine
under just make.



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: problems with threads/destructors in -current with llvm/clang

[Mark Atkinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/07/2012 09:29, Dimitry Andric wrote:
> On 2012-12-07 17:43, Mark Atkinson wrote:
>> On 12/7/2012 6:08 AM, Dimitry Andric wrote:
> ...
>>> With this patch (placed in /usr/ports/devel/dbus-qt4/files),
>>> qdbus starts up and exits normally for me.  I did not do any
>>> other rigorous testing, though. :)
>> 
>> Thanks for the awesome analysis.  I will endeavor to figure out
>> the bug in automoc4 that keeps it segfaulting randomly during
>> compilation.
>> 
>> Weirdly it segfaults reliably under portmaster, but may work just
>> fine under just make.
> 
> Try running it under valgrind.  If it does undefined things, it may
> work or not work randomly, and valgrind usually catches this.

OK, so this one's a bit of a headscratcher, but maybe someone has some
ideas.  automoc4 always dies in libthr.

#0  0x2864b1da in swapcontext () from /lib/libthr.so.3
[New Thread 29003800 (LWP 100960/automoc4.bin)]
[New Thread 29003080 (LWP 101795/automoc4.bin)]
(gdb) bt
#0  0x2864b1da in swapcontext () from /lib/libthr.so.3
#1  0x2864a046 in pthread_getspecific () from /lib/libthr.so.3
#2  0x28649e9a in pthread_getspecific () from /lib/libthr.so.3
#3  0x2864dbfb in pthread_kill () from /lib/libthr.so.3
#4  0x28064e71 in _rtld_get_stack_prot () from /libexec/ld-elf.so.1
#5  0x2865d500 in _thread_state_running () from /lib/libthr.so.3
#6  0x2865d500 in _thread_state_running () from /lib/libthr.so.3
#7  0x28075e00 in ?? ()
#8  0x286b4d30 in pipe () from /lib/libc.so.7
#9  0x280712ac in ?? () from /libexec/ld-elf.so.1
#10 0xbf9fce2c in ?? ()
#11 0x2805e505 in r_debug_state () from /libexec/ld-elf.so.1
#12 0x28071f68 in ?? () from /libexec/ld-elf.so.1
#13 0xbf9fcde0 in ?? ()
#14 0xbf9fce18 in ?? ()
#15 0x0001 in ?? ()
#16 0x in ?? ()
(gdb) thread 2
[Switching to thread 2 (Thread 29003080 (LWP 101795/automoc4.bin))]#0
 0x2876c3a7 in select () from /lib/libc.so.7
(gdb) bt
#0  0x2876c3a7 in select () from /lib/libc.so.7
#1  0x286481ab in select () from /lib/libthr.so.3
#2  0x28365c49 in qt_safe_select (nfds=17, fdread=0xbfbfa090,
fdwrite=0xbfbfa010, fdexcept=0x0, orig_timeout=0x0) at
kernel/qcore_unix.cpp:83
#3  0x282c23b2 in select_msecs (nfds=17, fdread=0xbfbfa090,
fdwrite=0xbfbfa010, timeout=-1) at io/qprocess_unix.cpp:998
#4  0x282c33f3 in QProcessPrivate::waitForFinished (this=0x29089300,
msecs=-1) at io/qprocess_unix.cpp:1219
#5  0x28240b50 in QProcess::waitForFinished (this=0xbfbfa1e8,
msecs=-1) at io/qprocess.cpp:1759
#6  0x0805487b in AutoMoc::echoColor (this=0xbfbfab00,
msg=@0xbfbfa2e0) at
/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:74
#7  0x08052650 in AutoMoc::generateMoc (this=0xbfbfab00,
sourceFile=@0x29011658, mocFileName=@0x2901165c) at
/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:569
#8  0x0804f13b in AutoMoc::run (this=0xbfbfab00) at
/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:470
#9  0x0804aaef in main (argc=6, argv=0xbfbfab98) at
/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:114

I noticed that qt_safe_select() used a register bound variable for the
return value, but removing that didn't alleviate the error.

The pthread_getspecific() manpage mentions that if the key is deleted
then the behavior is undefined -- so maybe this?  It's definitely
seems like a race condition of some kind.

Valgrind will kill any run of automoc4 and doesn't like some
instruction after the qt_safe_select() call:

vex x86->IR: unhandled instruction bytes: 0xF 0xB 0x90 0x90
==33074== valgrind: Unrecognised instruction at address 0x380434e9.
==33074==at 0x380434E9: ??? (in
/usr/local/lib/valgrind/memcheck-x86-freebsd)
==33074==by 0x323C48: qt_safe_select(int, fd_set*, fd_set*,
fd_set*, timeval const*) (qcore_unix.cpp:83)
==33074==by 0x2803B1: select_msecs(int, fd_set*, fd_set*, int)
(qprocess_unix.cpp:998)
==33074==by 0x28021D: QProcessPrivate::waitForStarted(int)
(qprocess_unix.cpp:1031)
==33074==by 0x1FFA02: QProcess::waitForStarted(int)
(qprocess.cpp:1687)
==33074==by 0x1FEAEA: QProcess::waitForFinished(int)
(qprocess.cpp:1752)
==33074==by 0x805487A: AutoMoc::echoColor(QString const&)
(kde4automoc.cpp:74)
==33074==by 0x805264F: AutoMoc::generateMoc(QString const&,
QString const&) (kde4automoc.cpp:569)
==33074==by 0x804F13A: AutoMoc::run() (kde4automoc.cpp:470)
==33074==by 0x804AAEE: main (kde4automoc.cpp:114)

Full valgrind output is at http://pastebin.com/KQTKYGX5

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDGHWEACgkQrDN5kXnx8yZEUwCfXhKBqCJKJcfomG6mHo6ataaw
x60An36saeyL2b09CR2Z/zL84KzjPjsQ
=EzG3
-END PGP SIGNATURE-

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: problems with threads/destructors in -current with llvm/clang

[Mark Atkinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/10/2012 10:25, Konstantin Belousov wrote:
> On Mon, Dec 10, 2012 at 09:35:29AM -0800, Mark Atkinson wrote: On
> 12/07/2012 09:29, Dimitry Andric wrote:
>>>> On 2012-12-07 17:43, Mark Atkinson wrote:
>>>>> On 12/7/2012 6:08 AM, Dimitry Andric wrote:
>>>> ...
>>>>>> With this patch (placed in
>>>>>> /usr/ports/devel/dbus-qt4/files), qdbus starts up and
>>>>>> exits normally for me.  I did not do any other rigorous
>>>>>> testing, though. :)
>>>>> 
>>>>> Thanks for the awesome analysis.  I will endeavor to figure
>>>>> out the bug in automoc4 that keeps it segfaulting randomly
>>>>> during compilation.
>>>>> 
>>>>> Weirdly it segfaults reliably under portmaster, but may
>>>>> work just fine under just make.
>>>> 
>>>> Try running it under valgrind.  If it does undefined things,
>>>> it may work or not work randomly, and valgrind usually
>>>> catches this.
> 
> OK, so this one's a bit of a headscratcher, but maybe someone has
> some ideas.  automoc4 always dies in libthr.
>> Build rtld, libc and libthr with the debug symbols to get useful 
>> backtrace.
> 
> 
> #0  0x2864b1da in swapcontext () from /lib/libthr.so.3 [New Thread
> 29003800 (LWP 100960/automoc4.bin)] [New Thread 29003080 (LWP
> 101795/automoc4.bin)] (gdb) bt #0  0x2864b1da in swapcontext ()
> from /lib/libthr.so.3 #1  0x2864a046 in pthread_getspecific () from
> /lib/libthr.so.3 #2  0x28649e9a in pthread_getspecific () from
> /lib/libthr.so.3 #3  0x2864dbfb in pthread_kill () from
> /lib/libthr.so.3 #4  0x28064e71 in _rtld_get_stack_prot () from
> /libexec/ld-elf.so.1 #5  0x2865d500 in _thread_state_running ()
> from /lib/libthr.so.3 #6  0x2865d500 in _thread_state_running ()
> from /lib/libthr.so.3 #7  0x28075e00 in ?? () #8  0x286b4d30 in
> pipe () from /lib/libc.so.7 #9  0x280712ac in ?? () from
> /libexec/ld-elf.so.1 #10 0xbf9fce2c in ?? () #11 0x2805e505 in
> r_debug_state () from /libexec/ld-elf.so.1 #12 0x28071f68 in ?? ()
> from /libexec/ld-elf.so.1 #13 0xbf9fcde0 in ?? () #14 0xbf9fce18 in
> ?? () #15 0x0001 in ?? () #16 0x in ?? () (gdb) thread
> 2 [Switching to thread 2 (Thread 29003080 (LWP
> 101795/automoc4.bin))]#0 0x2876c3a7 in select () from
> /lib/libc.so.7 (gdb) bt #0  0x2876c3a7 in select () from
> /lib/libc.so.7 #1  0x286481ab in select () from /lib/libthr.so.3 #2
> 0x28365c49 in qt_safe_select (nfds=17, fdread=0xbfbfa090, 
> fdwrite=0xbfbfa010, fdexcept=0x0, orig_timeout=0x0) at 
> kernel/qcore_unix.cpp:83 #3  0x282c23b2 in select_msecs (nfds=17,
> fdread=0xbfbfa090, fdwrite=0xbfbfa010, timeout=-1) at
> io/qprocess_unix.cpp:998 #4  0x282c33f3 in
> QProcessPrivate::waitForFinished (this=0x29089300, msecs=-1) at
> io/qprocess_unix.cpp:1219 #5  0x28240b50 in
> QProcess::waitForFinished (this=0xbfbfa1e8, msecs=-1) at
> io/qprocess.cpp:1759 #6  0x0805487b in AutoMoc::echoColor
> (this=0xbfbfab00, msg=@0xbfbfa2e0) at 
> /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:74 
> #7  0x08052650 in AutoMoc::generateMoc (this=0xbfbfab00, 
> sourceFile=@0x29011658, mocFileName=@0x2901165c) at 
> /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:569 
> #8  0x0804f13b in AutoMoc::run (this=0xbfbfab00) at 
> /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:470 
> #9  0x0804aaef in main (argc=6, argv=0xbfbfab98) at 
> /usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:114
> 
> I noticed that qt_safe_select() used a register bound variable for
> the return value, but removing that didn't alleviate the error.
> 
> The pthread_getspecific() manpage mentions that if the key is
> deleted then the behavior is undefined -- so maybe this?  It's
> definitely seems like a race condition of some kind.
> 
> Valgrind will kill any run of automoc4 and doesn't like some 
> instruction after the qt_safe_select() call:
> 
> vex x86->IR: unhandled instruction bytes: 0xF 0xB 0x90 0x90
>> This is ud2, an instruction which generates a fault on purpose.
> 
>> So rebuild the system libraries with the debug symbols and show 
>> the backtrace.

Hmm.  Since I took out -O2 and added -g in rebuilding
libthr/libc/rtld, I figured I needed to reproduce a new segfault, but
the rtld side of things seems broken:

#0  0xbf9fd01a in ?? ()
[New Thread 29003800 (LWP 100652/automoc4.bin)]
[New Thread 29003080 (LWP 101395/automoc4.bin)]
(gdb) bt
#0  0xbf9fd01a in ?? ()
#1  0xbf9fcd20 in ?? ()
#2  0x in ?? ()
(gdb) info thread
  2 Thread 29003080 (LWP 101395/automoc4.bin)  select ()

Re: problems with threads/destructors in -current with llvm/clang

[Mark Atkinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/10/2012 12:33, Konstantin Belousov wrote:

> Hmm.  Since I took out -O2 and added -g in rebuilding 
> libthr/libc/rtld, I figured I needed to reproduce a new segfault,
> but the rtld side of things seems broken:
>> Use e.g. cd src/libexec/rtld-elf && make DEBUG_FLAGS=-g clean all
>> install This is really FAQ.


It _is_ strange, because I did almost exactly that (dumped a temporary
DEBUG_FLAGS/CFLAGS in /etc/make.conf)

The one I had problems with was libc since It needs a make depend in
there.

$ readelf -w /libexec/ld-elf.so.1 |head
The section .debug_aranges contains:

  Length:   28
  Version:  2
  Offset into .debug_info:  0
  Pointer Size: 4
  Segment Size: 0

AddressLength
0x0e80 0x49
$
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEUEARECAAYFAlDGSeMACgkQrDN5kXnx8yYb6QCfQFO6o/At+srdpuRfI8jGCnqu
ZJMAlir1UvA4mgE0k2ewP43ayPiepCM=
=YVai
-END PGP SIGNATURE-

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: problems with threads/destructors in -current with llvm/clang

[Mark Atkinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/10/2012 12:45, Mark Atkinson wrote:
> On 12/10/2012 12:33, Konstantin Belousov wrote:
> 
>> Hmm.  Since I took out -O2 and added -g in rebuilding 
>> libthr/libc/rtld, I figured I needed to reproduce a new
>> segfault, but the rtld side of things seems broken:
>>> Use e.g. cd src/libexec/rtld-elf && make DEBUG_FLAGS=-g clean
>>> all install This is really FAQ.
> 
> 
> It _is_ strange, because I did almost exactly that (dumped a
> temporary DEBUG_FLAGS/CFLAGS in /etc/make.conf)
> 
> The one I had problems with was libc since It needs a make depend
> in there.
> 
> $ readelf -w /libexec/ld-elf.so.1 |head The section .debug_aranges
> contains:
> 
> Length:   28 Version:  2 Offset
> into .debug_info:  0 Pointer Size: 4 Segment Size:
> 0
> 
> AddressLength 0x0e80 0x49 $

So ignoring this weirdness, running under valgrind always segfaults
and the core seems useful.

#0  0x0061bd59 in handle_signal (actp=0xbf9fd490, sig=20,
info=0xbf9fd7b0, ucp=0x0) at /usr/src/lib/libthr/thread/thr_sig.c:198
#1  0x0061b71c in thr_sighandler (sig=20, info=0xbf9fd7b0, _ucp=0x0)
at /usr/src/lib/libthr/thread/thr_sig.c:182
#2  0x380434dc in ?? ()
#3  0x0014 in ?? ()
#4  0xbf9fd7b0 in ?? ()
#5  0x in ?? ()
(gdb) frame 0
#0  0x0061bd59 in handle_signal (actp=0xbf9fd490, sig=20,
info=0xbf9fd7b0, ucp=0x0) at /usr/src/lib/libthr/thread/thr_sig.c:198
198 SIGSETOR(actp->sa_mask, ucp->uc_sigmask);
(gdb) list
193 int cancel_enable;
194 int in_sigsuspend;
195 int err;
196
197 /* add previous level mask */
198 SIGSETOR(actp->sa_mask, ucp->uc_sigmask);
199
200 /* add this signal's mask */
201 if (!(actp->sa_flags & SA_NODEFER))
202 SIGADDSET(actp->sa_mask, sig);

(gdb) p actp
$1 = (struct sigaction *) 0xbf9fd490
(gdb) p *actp
$2 = {__sigaction_u = {__sa_handler = 0x288310
, __sa_sigaction = 0x288310
}, sa_flags = 8, sa_mask = {__bits = {0,
0, 0, 0}}}
(gdb) p *ucp
Cannot access memory at address 0x0
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDGUHMACgkQrDN5kXnx8yYBDACfaBBZyDZnQhbxxjw46csLbg7z
X7UAn1ea4LbW8PHXL07BwraiVXakh1bU
=GktK
-END PGP SIGNATURE-

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: loopback interface broken on current

[Mark Atkinson]

On 1/1/2013 2:22 AM, Gleb Smirnoff wrote:
>   Manfred,
> 
> On Thu, Dec 27, 2012 at 09:05:26AM -0800, Manfred Antar wrote:
> M> For the past few days the loopback  interface 127.0.0.1 is broken on 
> current.
> M> The last good kernel that works for me is  r244662: Mon Dec 24 06:43:07 
> PST 2012
> M> Here are some of the errors from current today:
> 
> Can you please track this down to the specific revision that made the
> regression? The timeframe is samll, so binary search probably won't 
> take long time.
> 
> 

nc -l 127.0.0.1 

works for me on r244911




___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: clang 3.2 RC2 miscompiles libgcc?

[Mark Atkinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/04/2013 12:23, Konstantin Belousov wrote:
> On Fri, Jan 04, 2013 at 08:06:02PM +0100, Stefan Farfeleder wrote:
>> On Fri, Jan 04, 2013 at 08:14:38PM +0200, Konstantin Belousov
>> wrote:
>>> On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder
>>> wrote:
 Here's a minimal test case that reproduces the bug:
 
 $ cat throw-crash.cc #include 
 
 void f2(void) { std::string s; throw
 std::runtime_error("foo"); }
 
 void f1(void) { f2(); }
 
 int main(void) { try { std::string s1, s2; f1(); return 0; }
 catch (const std::exception &) { return 1; } } $ g++ -O2
 -finline-limit=0 throw-crash.cc $ ./a.out zsh: bus error
 (core dumped)  ./a.out
>>> 
>>> What is the backtrace ? Compile the system libraries (ld-elf,
>>> libc, libgcc etc) with the debugging information and obtain the
>>> backtrace once more.
>> 
>> I'm afraid the backtrace is not really interesting:
>> 
>> Program received signal SIGBUS, Bus error. 
>> std::string::_Rep::_M_dispose (this=0x7fffd62fe8,
>> __a=@0x7fffd628) at atomicity.h:69 69  _Atomic_word
>> __result = *__mem; (gdb) bt #0  std::string::_Rep::_M_dispose
>> (this=0x7fffd62fe8, __a=@0x7fffd628) at atomicity.h:69 #1
>> 0x00080089d168 in ~basic_string (this=0x7fffd62fe8) at
>> basic_string.h:482 #2  0x00401038 in main () at
>> throw-crash.cc:16
>> 
>> I think the stack is somehow corrupted after the exception was 
>> performed. As with the original test case, loading an old
>> libgcc_s.so.1 instead makes the program run correctly.
>> 
>> It seems the std::string destructor is called with an invalid
>> this pointer for s2:
>> 
>> (gdb) r Starting program: /usr/home/stefan/scratch/a.out
>> 
>> Breakpoint 1, main () at throw-crash.cc:12 12  int main(void)
>> { (gdb) b _Unwind_RaiseException Breakpoint 2 at 0x800d420b4 
>> (gdb) c Continuing.
>> 
>> Breakpoint 2, 0x000800d420b4 in _Unwind_RaiseException () 
>> from /lib/libgcc_s.so.1 (gdb) f 2 #2  0x00400f51 in f2 ()
>> at throw-crash.cc:5 5   throw std::runtime_error("foo"); 
>> (gdb) p &s $1 = (string *) 0x7fffd600 (gdb) up #3
>> 0x00400fe2 in main () at throw-crash.cc:15 15
>> f1(); (gdb) p &s1 $2 = (string *) 0x7fffd650 (gdb) p &s2 $3 =
>> (string *) 0x7fffd640  (gdb) b 'std::basic_string> std::char_traits, std::allocator >::~basic_string()'
>>  Breakpoint 3 at 0x80089d154: file basic_string.h, line 482. 
>> (gdb) c Continuing.
>> 
>> Breakpoint 3, ~basic_string (this=0x7fffd600) at
>> basic_string.h:279 279   _M_data() const (gdb) c 
>> Continuing.
>> 
>> Breakpoint 3, ~basic_string (this=0x7fffd640) at
>> basic_string.h:279 279   _M_data() const (gdb) c 
>> Continuing.
>> 
>> Breakpoint 3, ~basic_string (this=0x7fffd60f) at
>> basic_string.h:279  279   _M_data() const
>> 
>> So, the address of s2 is 0x7fffd640, but the dtor is called
>> with 0x7fffd60f which is also very unaligned. I think this is
>> the reason for the crash.
> 
> Thank you for digging more.
> 
> In fact, it is more likely that there is some bug or
> incompatibility in c++ unwinder than in the libgcc itself, but as
> you noted, a compiler bug is also possible.
> 
> Anyway, I was mostly looking could the backtrace starts in rtld.
> Rtld bug also cannot be excluded at this stage, but it not much
> likely.
> 

Since this is similar to the pain I was seeing rebuilding everything
with clang so I have been following this thread with much interest.

Just to add more data, I get different results.   This is all i386.

gcc v464 built using an earlier clang from -current world/kernel
r243027.  boost was also built using this revision.

$ /usr/local/bin/g++46 -O2 -I/usr/local/include -L/usr/local/lib
- -lboost_program_options -o unwinder unwinder.cc
[atkinson@moby ~/dev]$ ldd unwinder
unwinder:
libboost_program_options.so =>
/usr/local/lib/libboost_program_options.so (0x2806e000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x280c2000)
libm.so.5 => /lib/libm.so.5 (0x281a1000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x281c2000)
libc.so.7 => /lib/libc.so.7 (0x281cd000)
libthr.so.3 => /lib/libthr.so.3 (0x28317000)
[atkinson@moby ~/dev]$ ./unwinder
Abort trap (core dumped)


clang 32 built from -current world/kernel r244958 works just fine.

$ c++ -O2 -I/usr/local/include -L/usr/local/lib
- -lboost_program_options -o unwinder unwinder.cc
[atkinson@moby ~/dev]$ ./unwinder
[atkinson@moby ~/dev]$ ldd unwinder
unwinder:
libboost_program_options.so =>
/usr/local/lib/libboost_program_options.so (0x2806d000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x280c1000)
libm.so.5 => /lib/libm.so.5 (0x281a)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x281c1000)
libc.so.7 => /lib/libc.so.7 (0x281cc000)
libthr.so.3 => /lib/libthr.so.3 (0x28316000)


It might be useful to exp

panic on vt / kms rv610

[Mark Atkinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I updated -current to r265915 w/ amd64 kernel and I get a panic
when I startx instantly (no video output of panic).   There is a LOR
right before the panic.

This is built using the VT kernel definition.

loading the old kernel built @ r264316 continues to load fine.

here's what normal under the old kernel looks like

$ kldstat
Id Refs AddressSize Name
 1   53 0x8020 19b8a48  kernel
 21 0x81c11000 9d81 linprocfs.ko
 31 0x81c1b000 44ba6linux.ko
 41 0x81c6 2349 ums.ko
 51 0x81c63000 6809 uftdi.ko
 61 0x81c6a000 3b95 ucom.ko
 71 0x81c6e000 16fd uhid.ko
 81 0x81c7 115db3   radeonkms.ko
 91 0x81d86000 48761drm2.ko
104 0x81dcf000 2004 iicbus.ko
111 0x81dd2000 1a3f iic.ko
121 0x81dd4000 1e35 iicbb.ko
131 0x81dd6000 1066 radeonkmsfw_RV610_pfp.ko
141 0x81dd8000 5b63 radeonkmsfw_RV610_me.ko
151 0x81dde000 1361 radeonkmsfw_R600_rlc.ko

relevant boot messages on problematic r265915:

May 12 23:41:00  moby kernel: VT: running with driver "vga".
[...]
May 12 23:41:00  moby kernel: vgapci0:  port 0xdc00-0xdcff mem
0xd000-0xdfff,0xfe9f-0xfe9f irq 16 at device 0.0 on pci1
May 12 23:41:00  moby kernel: vgapci0: Boot video device


Point of failure (also available at http://pastebin.com/scubtJE6 so
the line wrap doesn't make you go crazy):

May 12 23:42:05  moby kernel: info: [drm] Initialized drm
1.1.0 20060810
May 12 23:42:05  moby kernel: drmn0:  on
vgapci0
May 12 23:42:05  moby kernel: info: [drm] RADEON_IS_PCIE
May 12 23:42:05  moby kernel: info: [drm] initializing
kernel modesetting (RV610 0x1002:0x94C1 0x1028:0x0D02).
May 12 23:42:05  moby kernel: info: [drm] register mmio
base: 0xFE9F
May 12 23:42:05  moby kernel: info: [drm] register mmio
size: 65536
May 12 23:42:05  moby kernel: info: [drm]
radeon_atrm_get_bios: ===> Try ATRM...
May 12 23:42:05  moby kernel: info: [drm]
radeon_atrm_get_bios: pci_find_class() found: 0:1:0:0, vendor=1002,
device=94c1
May 12 23:42:05  moby kernel: info: [drm]
radeon_atrm_get_bios: Get ACPI device handle
May 12 23:42:05  moby kernel: info: [drm]
radeon_acpi_vfct_bios: ===> Try VFCT...
May 12 23:42:05  moby kernel: info: [drm]
radeon_acpi_vfct_bios: Get "VFCT" ACPI table
May 12 23:42:05  moby kernel: info: [drm]
radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND
May 12 23:42:05  moby kernel: info: [drm]
igp_read_bios_from_vram: ===> Try IGP's VRAM...
May 12 23:42:05  moby kernel: info: [drm]
igp_read_bios_from_vram: VRAM base address: 0xd000
May 12 23:42:05  moby kernel: info: [drm]
igp_read_bios_from_vram: Map address: 0xf800d000 (262144 bytes)
May 12 23:42:05  moby kernel: info: [drm]
igp_read_bios_from_vram: Incorrect BIOS signature: 0x
May 12 23:42:05  moby kernel: info: [drm] radeon_read_bios:
===> Try PCI Expansion ROM...
May 12 23:42:05  moby kernel: info: [drm] radeon_read_bios:
Map address: 0xf80c (131072 bytes)
May 12 23:42:05  moby kernel: info: [drm] ATOM BIOS: 113
May 12 23:42:05  moby kernel: drmn0: info: VRAM: 256M
0x - 0x0FFF (256M used)
May 12 23:42:05  moby kernel: drmn0: info: GTT: 512M
0x1000 - 0x2FFF
May 12 23:42:05  moby kernel: info: [drm] Detected VRAM
RAM=256M, BAR=256M
May 12 23:42:05  moby kernel: info: [drm] RAM width 64bits DDR
May 12 23:42:05  moby kernel: [TTM] Zone  kernel: Available
graphics memory: 2016864 kiB
May 12 23:42:05  moby kernel: [TTM] Initializing pool allocator
May 12 23:42:05  moby kernel: info: [drm] radeon: 256M of
VRAM memory ready
May 12 23:42:05  moby kernel: info: [drm] radeon: 512M of
GTT memory ready.
May 12 23:42:05  moby kernel: info: [drm] Supports vblank
timestamp caching Rev 1 (10.10.2010).
May 12 23:42:05  moby kernel: info: [drm] Driver supports
precise vblank timestamp query.
May 12 23:42:05  moby kernel: info: [drm] radeon: irq
initialized.
May 12 23:42:05  moby kernel: info: [drm] GART: num cpu
pages 131072, num gpu pages 131072
May 12 23:42:05  moby kernel: info: [drm] probing gen 2
caps for device 8086:29b1 = 1/0
May 12 23:42:05  moby kernel: info: [drm] Loading RV610
Microcode
May 12 23:42:05  moby kernel: firmware:
'radeonkmsfw_RV610_pfp' version 0: 2304 bytes loaded at 0x81fd60d0
May 12 23:42:05  moby kernel: firmware:
'radeonkmsfw_RV610_me' version 0: 21504 bytes loaded at 0x81fd80d0
May 12 23:42:05  moby kernel: firmware:
'radeonkmsfw_R600_rlc' version 0: 3072 bytes loaded at 0x81fde0d0
May 12 23:42:05  moby kernel: info: [drm] PCIE GART of 512M
enabled (table at 0x0004).
May 12 23:42:05  moby kernel: drmn0: info: WB enabled
May 12 23:42:05  moby kernel: drmn0: info: fence driver on
ring 0 use gpu addr 0x1c00 and cpu addr 0x0xf80076c33c00
May 12 23:42:05  

Re: panic on vt / kms rv610

[Mark Atkinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/15/2014 04:52, Aleksandr Rybalko wrote:
> On Wed, 14 May 2014 08:29:32 -0700 Mark Atkinson
>  wrote:
> 
> I updated -current to r265915 w/ amd64 kernel and I get a panic 
> when I startx instantly (no video output of panic).   There is a
> LOR right before the panic.

>> Hello Mark,
> 
>> looks like it is kms driver load problem. I think updating to
>> r265927 or more fresh will fix your problem. Sorry for
>> inconvenience.

I knew I was missing that revision, but looking at the diff It didn't
seem like it would prevent loading, but low and behold it works.  Thanks!

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlN2HrAACgkQrDN5kXnx8ybCAwCgpzZY4INjEbzRy6ppGR+7CxNv
TcQAniC5uXTG6AE0QVug6wdiddcoAL7J
=ilGJ
-END PGP SIGNATURE-

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

New ufs LOR.

[Mark Atkinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mounted a drive with -o sync this morning on r266123 and got a LOR I
had not seen before (ufs/soft updates)

lock order reversal:
 1st 0xf8005904db78 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2101
 2nd 0xfe00efe72080 bufwait (bufwait) @
/usr/src/sys/ufs/ffs/ffs_vnops.c:262
 3rd 0xf8005921bb78 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2101
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe011a213380
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe011a213430
witness_checkorder() at witness_checkorder+0xdc2/frame 0xfe011a2134c0
__lockmgr_args() at __lockmgr_args+0x9ca/frame 0xfe011a2135f0
ffs_lock() at ffs_lock+0x84/frame 0xfe011a213640
VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfe011a213670
_vn_lock() at _vn_lock+0xaa/frame 0xfe011a2136e0
vget() at vget+0x67/frame 0xfe011a213720
vfs_hash_get() at vfs_hash_get+0xe1/frame 0xfe011a213770
ffs_vgetf() at ffs_vgetf+0x40/frame 0xfe011a213800
softdep_sync_buf() at softdep_sync_buf+0xafc/frame 0xfe011a2138e0
ffs_syncvnode() at ffs_syncvnode+0x286/frame 0xfe011a213960
softdep_fsync() at softdep_fsync+0x59e/frame 0xfe011a213a00
ffs_fsync() at ffs_fsync+0x60/frame 0xfe011a213a30
VOP_FSYNC_APV() at VOP_FSYNC_APV+0xf7/frame 0xfe011a213a60
sys_fsync() at sys_fsync+0x175/frame 0xfe011a213ae0
amd64_syscall() at amd64_syscall+0x25a/frame 0xfe011a213bf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe011a213bf0
- --- syscall (95, FreeBSD ELF64, sys_fsync), rip = 0x80308230a, rsp =
0x7fffe688, rbp = 0x7fffe6a0 ---


Also I always get this one during installworld for, like the last 2.5
years or more.   Any chance on nuking it?

lock order reversal:
 1st 0xfe00ef0962e0 bufwait (bufwait) @
/usr/src/sys/kern/vfs_bio.c:3081
 2nd 0xf8000652e400 dirhash (dirhash) @
/usr/src/sys/ufs/ufs/ufs_dirhash.c:284
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe011a009410
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe011a0094c0
witness_checkorder() at witness_checkorder+0xdc2/frame 0xfe011a009550
_sx_xlock() at _sx_xlock+0x75/frame 0xfe011a009590
ufsdirhash_add() at ufsdirhash_add+0x3a/frame 0xfe011a0095d0
ufs_direnter() at ufs_direnter+0x6a0/frame 0xfe011a009690
ufs_mkdir() at ufs_mkdir+0x89c/frame 0xfe011a009880
VOP_MKDIR_APV() at VOP_MKDIR_APV+0xf7/frame 0xfe011a0098b0
kern_mkdirat() at kern_mkdirat+0x209/frame 0xfe011a009ae0
amd64_syscall() at amd64_syscall+0x25a/frame 0xfe011a009bf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe011a009bf0
- --- syscall (136, FreeBSD ELF64, sys_mkdir), rip = 0x80095550a, rsp =
0x7fffea08, rbp = 0x7fffebd0 ---
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlN2IXkACgkQrDN5kXnx8yas9wCfdrUSzmr647EhHndH7RR5tSMI
QPAAnj+yA/XZQ+ZsnEc3l8SiC7q4L2n5
=gqxv
-END PGP SIGNATURE-

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

panic m_demote: m_nextpkt not NULL

[Mark Atkinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

r271093 GENERIC amd64.   Received this panic in the tcp reassembly code:

Unread portion of the kernel message buffer:
panic: m_demote: m_nextpkt not NULL
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe011331b410
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe011331b4c0
vpanic() at vpanic+0x189/frame 0xfe011331b540
kassert_panic() at kassert_panic+0x139/frame 0xfe011331b5b0
m_demote() at m_demote+0x79/frame 0xfe011331b5e0
sbappendstream_locked() at sbappendstream_locked+0x4b/frame
0xfe011331b600
tcp_reass() at tcp_reass+0x3bd/frame 0xfe011331b660
tcp_do_segment() at tcp_do_segment+0x1b01/frame 0xfe011331b750
tcp_input() at tcp_input+0xf67/frame 0xfe011331b890
ip_input() at ip_input+0xce/frame 0xfe011331b8e0
netisr_dispatch_src() at netisr_dispatch_src+0x86/frame 0xfe011331b950
ether_demux() at ether_demux+0x141/frame 0xfe011331b980
ether_nh_input() at ether_nh_input+0x32a/frame 0xfe011331b9b0
netisr_dispatch_src() at netisr_dispatch_src+0x86/frame 0xfe011331ba20
ether_input() at ether_input+0x4f/frame 0xfe011331ba50
if_input() at if_input+0xa/frame 0xfe011331ba60
em_rxeof() at em_rxeof+0x2bd/frame 0xfe011331bae0
em_handle_que() at em_handle_que+0x40/frame 0xfe011331bb20
taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame
0xfe011331bb80
taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame
0xfe011331bbb0
fork_exit() at fork_exit+0x84/frame 0xfe011331bbf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe011331bbf0
- --- trap 0, rip = 0, rsp = 0xfe011331bcb0, rbp = 0 ---
Uptime: 41m32s
Dumping 357 out of 3937
MB:..5%..14%..23%..32%..41%..54%..63%..72%..81%..95%


(kgdb) bt
#0  doadump (textdump=1) at pcpu.h:219
#1  0x8090d6b7 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:447
#2  0x8090dc58 in vpanic (fmt=,
ap=) at /usr/src/sys/kern/kern_shutdown.c:746
#3  0x8090da89 in kassert_panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:634
#4  0x80983b59 in m_demote (m0=0xf80067044c00,
all=) at /usr/src/sys/kern/uipc_mbuf.c:402
#5  0x8098b0ab in sbappendstream_locked (sb=0xf8009914c090,
m=0xf80067044c00) at /usr/src/sys/kern/uipc_sockbuf.c:532
#6  0x80ac15ed in tcp_reass (tp=0xf80099115000,
th=, tlenp=,
m=) at /usr/src/sys/netinet/tcp_reass.c:264
#7  0x80abbb41 in tcp_do_segment (m=0xf80067044c00,
th=0xf80067091022, so=0xf8009914c000, tp=,
drop_hdrlen=, tlen=1448, ti_locked=1)
at /usr/src/sys/netinet/tcp_input.c:2917
#8  0x80ab9667 in tcp_input (mp=,
offp=, proto=0)
at /usr/src/sys/netinet/tcp_input.c:1383
#9  0x80a4f6fe in ip_input (m=0x0)
at /usr/src/sys/netinet/ip_input.c:729
#10 0x809e9046 in netisr_dispatch_src (proto=,
source=, m=0xf80067044c00)
at /usr/src/sys/net/netisr.c:968
#11 0x809dfe91 in ether_demux (ifp=,
m=0xf80067044c00) at /usr/src/sys/net/if_ethersubr.c:775
#12 0x809e0bea in ether_nh_input (m=)
at /usr/src/sys/net/if_ethersubr.c:582
#13 0x809e9046 in netisr_dispatch_src (proto=,
source=, m=0xf80067044c00)
at /usr/src/sys/net/netisr.c:968
#14 0x809e019f in ether_input (ifp=0xf80002c08000, m=0x0)
at /usr/src/sys/net/if_ethersubr.c:683
#15 0x809dd1da in if_input (ifp=0x0, sendmp=0x0)
at /usr/src/sys/net/if.c:3909
#16 0x804dd51d in em_rxeof (count=99)
at /usr/src/sys/dev/e1000/if_em.c:4485
#17 0x804dce00 in em_handle_que (context=0xfed23000,
pending=) at /usr/src/sys/dev/e1000/if_em.c:1522
#18 0x80956bb0 in taskqueue_run_locked (queue=0xf80002957000)
at /usr/src/sys/kern/subr_taskqueue.c:356
#19 0x809576ab in taskqueue_thread_loop (arg=)
at /usr/src/sys/kern/subr_taskqueue.c:623
#20 0x808db5f4 in fork_exit (
callout=0x80957610 ,
arg=0xfed25738, frame=0xfe011331bc00)
at /usr/src/sys/kern/kern_fork.c:977
#21 0x80d0607e in fork_trampoline ()
at /usr/src/sys/amd64/amd64/exception.S:605
#22 0x in ?? ()
(kgdb) frame 4
#4  0x80983b59 in m_demote (m0=0xf80067044c00,
all=) at /usr/src/sys/kern/uipc_mbuf.c:402
402 KASSERT(m->m_nextpkt == NULL,
(kgdb) list
397 m_tag_delete_chain(m, NULL);
398 m->m_flags &= ~M_PKTHDR;
399 bzero(&m->m_pkthdr, sizeof(struct
pkthdr));
400 }
401 if (m != m0 && m->m_nextpkt != NULL) {
402 KASSERT(m->m_nextpkt == NULL,
403 ("%s: m_nextpkt not NULL", __func__));
404 m_freem(m->m_nextpkt);
405 m->m_nextpkt = NULL;
406 

Re: panic m_demote: m_nextpkt not NULL

[Mark Atkinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/05/2014 12:24, Gleb Smirnoff wrote:
> On Fri, Sep 05, 2014 at 08:38:10AM -0700, Mark Atkinson wrote: M>
> r271093 GENERIC amd64.   Received this panic in the tcp reassembly
> code: M> Unread portion of the kernel message buffer: M> panic:
> m_demote: m_nextpkt not NULL M> cpuid = 0
> 
> Sorry for that. Was fixed in r271123.

Thank you and Jean-Sébastien for the pointer, I was able rebuild the
kernel quickly on Fri with just this change and it's working fine.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlQN2jgACgkQrDN5kXnx8yZjlgCfcIyo87hclmT7YPVws/X0DAap
PK8AoKA7G9IQGO7Om0s0fXkwvzGtKZaR
=HSx2
-END PGP SIGNATURE-

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"