Signal 11 and the amd64 port

[Francois Tigeot-2]

I just installed a new DragonFly/amd64 system on a blank disk. Most of the
basic applications (base system, non-graphic packages) work fine.

While building applications from pkgsrc, I noticed many crashes of make(1)
with signal 11s. Nevertheless, I was able to install most of the programs I
wanted.

Things took a turn for the worse when I tried to run X11. None of the window
managers I tested could run. They all crashed with signal 11s.
The only application I was able to run under X is xterm. All others I could
test crashed immediately after launch.

I don't believe the new amd64 port should be so unstable. My test machine is
a Core 2 Duo system and runs DragonFly/i386 perfectly fine.

What can I do to find out what's wrong with X11 applications ?

--
Francois Tigeot

[Matthew Dillon]

:I just installed a new DragonFly/amd64 system on a blank disk. Most of the
:basic applications (base system, non-graphic packages) work fine.
:
:While building applications from pkgsrc, I noticed many crashes of make(1)
:with signal 11s. Nevertheless, I was able to install most of the programs I
:wanted.

    You mean bmake ?  pkgsrc uses bmake.

:Things took a turn for the worse when I tried to run X11. None of the window
:managers I tested could run. They all crashed with signal 11s.
:The only application I was able to run under X is xterm. All others I could
:test crashed immediately after launch.
:
:I don't believe the new amd64 port should be so unstable. My test machine is
:a Core 2 Duo system and runs DragonFly/i386 perfectly fine.
:
:What can I do to find out what's wrong with X11 applications ?
:
:--
:Francois Tigeot

    I haven't tried X stuff yet but we are not seeing any signal 11's on
    our 64-bit package source building box, other then from 'conftest'
    which is supposed to crash.

    I'll update to the latest master just to make sure some recent commit
    did not create an issue.

    I'm not sure what the issue could be if 32-bit works fine on the box.
    Do you have the system frequency tuned up or is it running stock?

                                        -Matt
                                        Matthew Dillon
                                        <dillon@...>

[Jordan Gordeev]

Francois Tigeot wrote:

>I just installed a new DragonFly/amd64 system on a blank disk. Most of the
>basic applications (base system, non-graphic packages) work fine.
>
>While building applications from pkgsrc, I noticed many crashes of make(1)
>with signal 11s. Nevertheless, I was able to install most of the programs I
>wanted.
>
>Things took a turn for the worse when I tried to run X11. None of the window
>managers I tested could run. They all crashed with signal 11s.
>The only application I was able to run under X is xterm. All others I could
>test crashed immediately after launch.
>
>I don't believe the new amd64 port should be so unstable. My test machine is
>a Core 2 Duo system and runs DragonFly/i386 perfectly fine.
>
>What can I do to find out what's wrong with X11 applications ?
>
>  
>

X support for the amd64 port was added just a few days ago and nobody
has put the effort yet to make it work well.
 From my very limited testing, xdm and twm seem to work, while e16 crashes.
What can you do? You can compile everything with debugging information
and obtain core files of the crashing apps. Then you can (try to)
analyse the core files with gdb.
To compile the base system with full debugging information you put the
following in /etc/make.conf:
    CFLAGS+=-g
    STRIP=
To build pkgsrc packages with full debugging information you put the
following into /usr/pkg/etc/mk.conf:
    CFLAGS+=-g
    INSTALL_UNSTRIPPED=yes
You can also use ktrace in your debugging.

[Francois Tigeot-2]

On Mon, Sep 21, 2009 at 10:51:40AM -0700, Matthew Dillon wrote:
>
> :I just installed a new DragonFly/amd64 system on a blank disk. Most of the
> :basic applications (base system, non-graphic packages) work fine.
> :
> :While building applications from pkgsrc, I noticed many crashes of make(1)
> :with signal 11s. Nevertheless, I was able to install most of the programs I
> :wanted.
>
>     You mean bmake ?  pkgsrc uses bmake.

I didn't really pay attention at the moment.
I definitely saw some gmake processes in the lot.

> :Things took a turn for the worse when I tried to run X11. None of the window
> :managers I tested could run. They all crashed with signal 11s.
> :The only application I was able to run under X is xterm. All others I could
> :test crashed immediately after launch.
>
>     I haven't tried X stuff yet but we are not seeing any signal 11's on
>     our 64-bit package source building box, other then from 'conftest'
>     which is supposed to crash.
>
>     I'll update to the latest master just to make sure some recent commit
>     did not create an issue.

I have updated the system. The only changes I got where in hammer and
sys/platform/pc64/amd64/sysarch.c
Applications still crash as before.

>     I'm not sure what the issue could be if 32-bit works fine on the box.
>     Do you have the system frequency tuned up or is it running stock?

It is running stock, with good cooling and a reputable brand power supply.
And since I am really a stability fan, the mainboard features ECC memory.

--
Francois Tigeot

[Francois Tigeot-2]

On Mon, Sep 21, 2009 at 10:37:54PM +0300, Jordan Gordeev wrote:

> Francois Tigeot wrote:
>
> >I just installed a new DragonFly/amd64 system on a blank disk. Most of the
> >basic applications (base system, non-graphic packages) work fine.
> >
> >While building applications from pkgsrc, I noticed many crashes of make(1)
> >with signal 11s. Nevertheless, I was able to install most of the programs I
> >wanted.
> >
> >Things took a turn for the worse when I tried to run X11. None of the
> >window
> >managers I tested could run. They all crashed with signal 11s.
> >The only application I was able to run under X is xterm. All others I could
> >test crashed immediately after launch.
> >
> X support for the amd64 port was added just a few days ago and nobody
> has put the effort yet to make it work well.

I also got crashes in console applications.

> From my very limited testing, xdm and twm seem to work, while e16 crashes.

Wmaker and xfwm4 also crash. Xterm is fine.

> What can you do? You can compile everything with debugging information
> and obtain core files of the crashing apps. Then you can (try to)
> analyse the core files with gdb.
> To compile the base system with full debugging information you put the
> following in /etc/make.conf:
>    CFLAGS+=-g
>    STRIP=
> To build pkgsrc packages with full debugging information you put the
> following into /usr/pkg/etc/mk.conf:
>    CFLAGS+=-g
>    INSTALL_UNSTRIPPED=yes
> You can also use ktrace in your debugging.

Thanks. I will change the flags and recompile everything.

In the meantime, this is the end of my amd64 dmesg:

[...]
Mounting devfs
seg-fault accessing address 0x8400000 rip=0x8017e5ae4 pid=836 p_comm=wmaker pid 836 (wmaker), uid 1000: exited on signal 11 (core dumped)
seg-fault accessing address 0x8400000 rip=0x8017e5ae4 pid=835 p_comm=wmaker pid 835 (wmaker), uid 1000: exited on signal 11 (core dumped)
seg-fault accessing address 0x5f0000 rip=0x800c1f37d pid=933 p_comm=mutt pid 933 (mutt), uid 1000: exited on signal 11 (core dumped)
seg-fault accessing address 0x5b0000 rip=0x80243d37d pid=969 p_comm=seamonkey-bin
pid 969 (seamonkey-bin), uid 1000: exited on signal 11 (core dumped)

--
Francois Tigeot

[Simon 'corecode' Schubert]

Francois Tigeot wrote:
> [...]
> Mounting devfs
> seg-fault accessing address 0x8400000 rip=0x8017e5ae4 pid=836 p_comm=wmaker pid 836 (wmaker), uid 1000: exited on signal 11 (core dumped)
> seg-fault accessing address 0x8400000 rip=0x8017e5ae4 pid=835 p_comm=wmaker pid 835 (wmaker), uid 1000: exited on signal 11 (core dumped)
> seg-fault accessing address 0x5f0000 rip=0x800c1f37d pid=933 p_comm=mutt pid 933 (mutt), uid 1000: exited on signal 11 (core dumped)
> seg-fault accessing address 0x5b0000 rip=0x80243d37d pid=969 p_comm=seamonkey-bin
> pid 969 (seamonkey-bin), uid 1000: exited on signal 11 (core dumped)

seems like mmap or linker issues.

cheers
   simon

--
   <3 the future  +++  RENT this banner advert  +++   ASCII Ribbon   /"\
   rock the past  +++  space for low CHF NOW!1  +++     Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \

[Matthew Dillon]

    I think its safe to say that we're going to see a lot of issue
    crop up with regards to 64-bit support, and its going to be
    difficult to sort out which ones are due to issues in the kernel
    and which ones are due to issues in third party programs compiled
    via pkgsrc.

    We've only just begun trying to run larger pkgsrc apps on 64-bit.
    The bulk build mechanics work very well and the build system doesn't
    crash even under extreme bulk-building loads, so we have definitely
    cleared a number of major hurtles.

                                                -Matt

[Francois Tigeot-2]

On Mon, Sep 21, 2009 at 08:10:48PM -0700, Matthew Dillon wrote:
>     I think its safe to say that we're going to see a lot of issue
>     crop up with regards to 64-bit support, and its going to be
>     difficult to sort out which ones are due to issues in the kernel
>     and which ones are due to issues in third party programs compiled
>     via pkgsrc.

I've found out mutt to be a non-X11 application which crashes very
reliably.

mutt.core and ktrace.out files are here:
http://www.wolfpond.org/crash.dfly/

--
Francois Tigeot

[Simon 'corecode' Schubert]

Francois Tigeot wrote:
> I've found out mutt to be a non-X11 application which crashes very
> reliably.
>
> mutt.core and ktrace.out files are here:
> http://www.wolfpond.org/crash.dfly/

Can you put up the mutt binary as well?

--
   <3 the future  +++  RENT this banner advert  +++   ASCII Ribbon   /"\
   rock the past  +++  space for low CHF NOW!1  +++     Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \

[Matthias Schmidt-12]

* Francois Tigeot wrote:

> On Mon, Sep 21, 2009 at 08:10:48PM -0700, Matthew Dillon wrote:
> >     I think its safe to say that we're going to see a lot of issue
> >     crop up with regards to 64-bit support, and its going to be
> >     difficult to sort out which ones are due to issues in the kernel
> >     and which ones are due to issues in third party programs compiled
> >     via pkgsrc.
>
> I've found out mutt to be a non-X11 application which crashes very
> reliably.
>
> mutt.core and ktrace.out files are here:
> http://www.wolfpond.org/crash.dfly/

HTTP request sent, awaiting response... 403 Forbidden
2009-09-22 11:15:42 ERROR 403: Forbidden.


Cheers

        Matthias

[Francois Tigeot-2]

On Tue, Sep 22, 2009 at 11:08:45AM +0200, Simon 'corecode' Schubert wrote:
> Francois Tigeot wrote:
> >I've found out mutt to be a non-X11 application which crashes very
> >reliably.
> >
> >mutt.core and ktrace.out files are here:
> >http://www.wolfpond.org/crash.dfly/
>
> Can you put up the mutt binary as well?

Sure, I have put it with the other files.

--
Francois Tigeot

[Francois Tigeot-2]

On Tue, Sep 22, 2009 at 11:16:25AM +0200, Matthias Schmidt wrote:

> * Francois Tigeot wrote:
> > On Mon, Sep 21, 2009 at 08:10:48PM -0700, Matthew Dillon wrote:
> > >     I think its safe to say that we're going to see a lot of issue
> > >     crop up with regards to 64-bit support, and its going to be
> > >     difficult to sort out which ones are due to issues in the kernel
> > >     and which ones are due to issues in third party programs compiled
> > >     via pkgsrc.
> >
> > I've found out mutt to be a non-X11 application which crashes very
> > reliably.
> >
> > mutt.core and ktrace.out files are here:
> > http://www.wolfpond.org/crash.dfly/
>
> HTTP request sent, awaiting response... 403 Forbidden
> 2009-09-22 11:15:42 ERROR 403: Forbidden.

Sorry about that, I have fixed the permissions.

--
Francois Tigeot

[Francois Tigeot-2]

On Thu, Oct 01, 2009 at 01:15:18PM +0300, Jordan Gordeev wrote:

> Francois Tigeot wrote:
> >I've found out mutt to be a non-X11 application which crashes very
> >reliably.
> >
> >mutt.core and ktrace.out files are here:
> >http://www.wolfpond.org/crash.dfly/
> >
> You would have helped yourself tremendously, if you would have provided
> the stack trace of the crashing binary in textual form.
> The way to obtain it is to run "gdb <executable> <corefile>" and run the
> "bt" command.

Thanks for the tip. I've put the stack trace below:

Core was generated by `mutt'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000000800c1f37d in libintl_dcigettext (domainname=0x8006900d0 "mutt",
    msgid1=0x47521e "Reading %s...", msgid2=0x0, plural=0, n=0, category=6)
    at ./dcigettext.c:669
669     ./dcigettext.c: No such file or directory.
        in ./dcigettext.c
(gdb) bt
#0  0x0000000800c1f37d in libintl_dcigettext (domainname=0x8006900d0 "mutt",
    msgid1=0x47521e "Reading %s...", msgid2=0x0, plural=0, n=0, category=6)
        at ./dcigettext.c:669
#1  0x0000000800c1b738 in libintl_dcgettext (domainname=0x8005b3d18 "<C0> [",
    msgid=0x18 <Address 0x18 out of bounds>, category=1) at ./dcgettext.c:49
#2  0x0000000800c1b76a in libintl_gettext (
    msgid=0x18 <Address 0x18 out of bounds>) at ./gettext.c:57
#3  0x0000000000432fc4 in mx_open_mailbox (path=<value optimized out>,
    flags=0, pctx=0x0) at mx.c:675
#4  0x000000000042af52 in main (argc=1, argv=0x7ffffffff720) at main.c:838
(gdb)

> It would be nice if you can test with the latest master too, as some
> changes made may have fixed the problem.

Unfortunately, it didn't change anything for mutt.

My LANG environment variable was set to fr_FR.UTF-8.
Without any LANG stuff, mutt runs fine.

X11 applications crash with a different call sequence. I'll try to recompile
all relevant packages and libraries with -g and post again when I'm done.

--
Francois Tigeot

[Francois Tigeot-2]

On Sun, Oct 04, 2009 at 02:49:46PM +0200, Francois Tigeot wrote:
>
> X11 applications crash with a different call sequence. I'll try to recompile
> all relevant packages and libraries with -g and post again when I'm done.

I've put a stack trace for windowmaker below:

  Core was generated by `wmaker'.
  Program terminated with signal 11, Segmentation fault.
  #0  _XPutPixel32 (ximage=0x8023304b0, x=0, y=0, pixel=11381165) at ImUtil.c:740
  740     ImUtil.c: No such file or directory.
          in ImUtil.c
  (gdb) bt
  #0  _XPutPixel32 (ximage=0x8023304b0, x=0, y=0, pixel=11381165) at ImUtil.c:740
  #1  0x00000008006d7d55 in RConvertImage (context=0x8006802a0,
      image=0x800616820, pixmap=0x7ffffffff420) at convert.c:355
  #2  0x00000008006d9686 in RConvertImageMask (context=0x8006802a0,
      image=0x800616820, pixmap=0x7ffffffff420, mask=0x7ffffffff418,
      threshold=128) at convert.c:1014
  #3  0x000000000046988f in WMCreatePixmapFromRImage (scrPtr=0x8020900c0,
      image=0x0, threshold=36897968) at wpixmap.c:102
  #4  0x00000000004648b6 in WMCreateScreenWithRContext (display=0x8006a0100,
      screen=<value optimized out>, context=<value optimized out>)
      at widgets.c:427
  #5  0x0000000000465039 in WMCreateScreen (display=0x8006a0100, screen=0)
      at widgets.c:557
  #6  0x00000000004156f7 in wShowCrashingDialogPanel (whatSig=11)
      at dialog.c:1718
  #7  0x000000000042f918 in showCrashDialog (sig=11) at monitor.c:61
  #8  0x000000000042fb1a in MonitorLoop (argc=<value optimized out>,
      argv=<value optimized out>) at monitor.c:148
  #9  0x000000000042879b in main (argc=1, argv=0x7ffffffff918) at main.c:643
  (gdb)

--
Francois Tigeot