Re: xmlto failing with what looks like junk data
On Thu, Sep 25, 2014 at 09:23:24AM -0400, trondd wrote: Just an update (and apologies for previous top posting and message history) but we've only ever seen this error and crash while running xmlto. I would think (maybe wrongly) that a stack-protector issue would show up in other programs, too. Bash crashes while turning a innocent test(1) condition list into an array to feed into the test function. There is nothing obviously wrong with the code, and under single stepping it works just fine. Bash does however make heavy use of setjmp/longjmp around the crash site. It looks as if longjmp does not restore the context properly. Instead of exiting the test builtin, it runs for a second time but with bogus register values. Just a wild guess after poking at it for a couple of hours. Oh and the reason bash does not dump core is because xmlto installs an exit trap handler, messing things up even more.
Re: xmlto failing with what looks like junk data
There certainly are stack-protector issues with other programs on arm. Just saw a new one. All we've been doing is compiling since there are no arm snap packages. :) Maybe we'll see more runtime issues if anyone ever gets anything built they will use regularly. If someone is working towards a fix for this, at least a few of us would be happy to update and try to test/reproduce issues. c++ -D_REENTRANT -DU_HAVE_ATOMIC=0 -DU_HAVE_TIMEZONE=0 -I/usr/ports/pobj/icu4c-53.1/icu/source/i18n -I/usr/ports/pobj/icu4c-53.1/icu/source/common -DU_ATTRIBUTE_DEPRECATED= -DU_I18N_IMPLEMENTATION -O2 -pipe -O1 -fno-stack-protector -W -Wall -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long-c -DPIC -fPIC -o collationrootelements.o /usr/ports/pobj/icu4c-53.1/icu/source/i18n/collationrootelements.cpp execvp: /usr/ports/pobj/icu4c-53.1/bin: path too long execvp: /usr/bin: path too long execvp: /bin: path too long execvp: /usr/sbin: path too long execvp: /sbin: path too long execvp: /usr/local/bin: path too long execvp: /usr/local/bin: path too long execvp: /usr/X11R6/bin: path too long gmake[1]: 0?%??%??m%p?m%: Command not found /usr/ports/pobj/icu4c-53.1/icu/source/config/mh-bsd-gcc:43: recipe for target 'collationrootelements.o' failed gmake[1]: *** [collationrootelements.o] Error 127 gmake[1]: Leaving directory '/usr/ports/pobj/icu4c-53.1/build-arm/i18n' Makefile:141: recipe for target 'all-recursive' failed gmake: *** [all-recursive] Error 2
Re: xmlto failing with what looks like junk data
Just an update (and apologies for previous top posting and message history) but we've only ever seen this error and crash while running xmlto. I would think (maybe wrongly) that a stack-protector issue would show up in other programs, too.
Re: xmlto failing with what looks like junk data
On 2014/09/25 09:23, trondd wrote: Just an update (and apologies for previous top posting and message history) but we've only ever seen this error and crash while running xmlto. I would think (maybe wrongly) that a stack-protector issue would show up in other programs, too. There certainly are stack-protector issues with other programs on arm.
xmlto failing with what looks like junk data
Several of us are seeing failures building dbus with xmlto crashing on random files. It will also crash if you run xmlto manually on a file. It's not consistently crashing on the same file all of the time. It looks like it's printing out garbage memory. We are building on an early September snapshot on the Zaurus. Here is an example failure while building dbus: Making all in doc gmake[2]: Entering directory '/usr/ports/pobj/dbus-1.8.6/dbus-1.8.6/doc' /usr/local/bin/xmlto man dbus-cleanup-sockets.1.xml Writing dbus-cleanup-sockets.1 for refentry(dbuscleanupsockets1) rm: ß ß: File too long /usr/local/bin/xmlto man dbus-daemon.1.xml Writing dbus-daemon.1 for refentry(dbusdaemon1) /usr/local/bin/xmlto: line 622: 11775 Bus Error(core dumped ) $(BASH) $FORMAT post-process Makefile: 765: recipe for target 'dbus-daemon.1' failed
Re: xmlto failing with what looks like junk data
On 2014/09/21 11:31, trondd wrote: Several of us are seeing failures building dbus with xmlto crashing on random files. It will also crash if you run xmlto manually on a file. It's not consistently crashing on the same file all of the time. It looks like it's printing out garbage memory. We are building on an early September snapshot on the Zaurus. Here is an example failure while building dbus: Making all in doc gmake[2]: Entering directory '/usr/ports/pobj/dbus-1.8.6/dbus-1.8.6/doc' /usr/local/bin/xmlto man dbus-cleanup-sockets.1.xml Writing dbus-cleanup-sockets.1 for refentry(dbuscleanupsockets1) rm: ß ß: File too long These are 0xdf characters almost always from malloc(3) junking when freeing memory. Are you only seeing this on arm? I haven't seen this on other arch (and haven't used arm for a couple of releases). I wonder if it's anything to do with stack-protector. We aren't doing regular package builds on arm any more so no good way to pick up problems (except for things that also affect the base OS). /usr/local/bin/xmlto man dbus-daemon.1.xml Writing dbus-daemon.1 for refentry(dbusdaemon1) /usr/local/bin/xmlto: line 622: 11775 Bus Error(core dumped ) $(BASH) $FORMAT post-process Makefile: 765: recipe for target 'dbus-daemon.1' failed Have a look at the core file that's left around (presumably bash.core?) and see if there's anything useful in a backtrace.
Re: xmlto failing with what looks like junk data
On Sun, Sep 21, 2014 at 06:23:31PM +0100, Stuart Henderson wrote: On 2014/09/21 11:31, trondd wrote: Several of us are seeing failures building dbus with xmlto crashing on random files. It will also crash if you run xmlto manually on a file. It's not consistently crashing on the same file all of the time. It looks like it's printing out garbage memory. We are building on an early September snapshot on the Zaurus. Here is an example failure while building dbus: Making all in doc gmake[2]: Entering directory '/usr/ports/pobj/dbus-1.8.6/dbus-1.8.6/doc' /usr/local/bin/xmlto man dbus-cleanup-sockets.1.xml Writing dbus-cleanup-sockets.1 for refentry(dbuscleanupsockets1) rm: ß ß: File too long These are 0xdf characters almost always from malloc(3) junking when freeing memory. Are you only seeing this on arm? I haven't seen this on other arch (and haven't used arm for a couple of releases). I got a xmlto crash in dbus on sparc. Didn't have time to investigate yet. I wonder if it's anything to do with stack-protector. We aren't doing regular package builds on arm any more so no good way to pick up problems (except for things that also affect the base OS). /usr/local/bin/xmlto man dbus-daemon.1.xml Writing dbus-daemon.1 for refentry(dbusdaemon1) /usr/local/bin/xmlto: line 622: 11775 Bus Error(core dumped ) $(BASH) $FORMAT post-process Makefile: 765: recipe for target 'dbus-daemon.1' failed Have a look at the core file that's left around (presumably bash.core?) and see if there's anything useful in a backtrace.
Re: xmlto failing with what looks like junk data
Worked ok on amd64 and i386 Trying to get a useful backtrace for the core file. xmlto blows up on it's own without dumping the core. It is bash that core dumps during the dbus build. All I got out of the backtrace was one address 0x0005a5f8 in ?? () Rebuilding bash with debug symbols to try to get more info. On Sun, Sep 21, 2014 at 6:59 PM, Tobias Ulmer tobi...@tmux.org wrote: On Sun, Sep 21, 2014 at 06:23:31PM +0100, Stuart Henderson wrote: On 2014/09/21 11:31, trondd wrote: Several of us are seeing failures building dbus with xmlto crashing on random files. It will also crash if you run xmlto manually on a file. It's not consistently crashing on the same file all of the time. It looks like it's printing out garbage memory. We are building on an early September snapshot on the Zaurus. Here is an example failure while building dbus: Making all in doc gmake[2]: Entering directory '/usr/ports/pobj/dbus-1.8.6/dbus-1.8.6/doc' /usr/local/bin/xmlto man dbus-cleanup-sockets.1.xml Writing dbus-cleanup-sockets.1 for refentry(dbuscleanupsockets1) rm: ك ك: File too long These are 0xdf characters almost always from malloc(3) junking when freeing memory. Are you only seeing this on arm? I haven't seen this on other arch (and haven't used arm for a couple of releases). I got a xmlto crash in dbus on sparc. Didn't have time to investigate yet. I wonder if it's anything to do with stack-protector. We aren't doing regular package builds on arm any more so no good way to pick up problems (except for things that also affect the base OS). /usr/local/bin/xmlto man dbus-daemon.1.xml Writing dbus-daemon.1 for refentry(dbusdaemon1) /usr/local/bin/xmlto: line 622: 11775 Bus Error(core dumped ) $(BASH) $FORMAT post-process Makefile: 765: recipe for target 'dbus-daemon.1' failed Have a look at the core file that's left around (presumably bash.core?) and see if there's anything useful in a backtrace.
Re: xmlto failing with what looks like junk data
Now I can't find where it's dropping the core file. The one generated before recompiling bash has this backtrace (when loaded with the new bash) #0 0x0005a5f8 in list_length () #1 0x000803cc in strvec_from_word_list () #2 0x000230d4 in execute_disk_command () #3 0x00023a68 in execute_simple_command () #4 0x00021630 in $a () #5 0x00021630 in $a () Previous frame identical to this frame (corrupt stack?) On Sun, Sep 21, 2014 at 7:28 PM, trondd tro...@gmail.com wrote: Worked ok on amd64 and i386 Trying to get a useful backtrace for the core file. xmlto blows up on it's own without dumping the core. It is bash that core dumps during the dbus build. All I got out of the backtrace was one address 0x0005a5f8 in ?? () Rebuilding bash with debug symbols to try to get more info. On Sun, Sep 21, 2014 at 6:59 PM, Tobias Ulmer tobi...@tmux.org wrote: On Sun, Sep 21, 2014 at 06:23:31PM +0100, Stuart Henderson wrote: On 2014/09/21 11:31, trondd wrote: Several of us are seeing failures building dbus with xmlto crashing on random files. It will also crash if you run xmlto manually on a file. It's not consistently crashing on the same file all of the time. It looks like it's printing out garbage memory. We are building on an early September snapshot on the Zaurus. Here is an example failure while building dbus: Making all in doc gmake[2]: Entering directory '/usr/ports/pobj/dbus-1.8.6/dbus-1.8.6/doc' /usr/local/bin/xmlto man dbus-cleanup-sockets.1.xml Writing dbus-cleanup-sockets.1 for refentry(dbuscleanupsockets1) rm: ك ك: File too long These are 0xdf characters almost always from malloc(3) junking when freeing memory. Are you only seeing this on arm? I haven't seen this on other arch (and haven't used arm for a couple of releases). I got a xmlto crash in dbus on sparc. Didn't have time to investigate yet. I wonder if it's anything to do with stack-protector. We aren't doing regular package builds on arm any more so no good way to pick up problems (except for things that also affect the base OS). /usr/local/bin/xmlto man dbus-daemon.1.xml Writing dbus-daemon.1 for refentry(dbusdaemon1) /usr/local/bin/xmlto: line 622: 11775 Bus Error(core dumped ) $(BASH) $FORMAT post-process Makefile: 765: recipe for target 'dbus-daemon.1' failed Have a look at the core file that's left around (presumably bash.core?) and see if there's anything useful in a backtrace.
