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,
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
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.
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
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
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.
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
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
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
