Bug#595977: [jimoow@gmail.com: Re: [mt1@systella.fr: Bug#595977: /usr/bin/ooffice: *** glibc detected *** /usr/lib/openoffice/program/soffice.bin: double free or corruption]]
On Tue, Sep 14, 2010 at 09:35:01PM +0200, BERTRAND Joël wrote:
> I have tried. It seems to be a good workaround. I don't see error anymore.
Ok, this is puzzling.
If I look at http://www.novell.com/support/viewContent.do?externalId=3113982&sliceId=1 it seems that 2 also does abort(), which also is confirmed by this
chat with the glibc maintainer yesterday:
21:46 < _rene_> aurel32: ping?
21:52 < aurel32> _rene_: pong
21:53 -!- roodie [~evil@541BE4EE.cm-5-4d.dynamic.ziggo.nl] has quit [Remote host
closed the connection]
21:53 < _rene_> aurel32: I am confused (maybe because I don't have much clue abo
ut system/glibc internals). See #595977 for the story
21:54 < _rene_> aurel32: the workaround apparently works, but the docs for the v
ar says it'd react with a abort() in such cases
21:54 < _rene_> aurel32: why does the workaround then work?
21:54 < _rene_> (and what does that have for side-effects?)
21:55 < lucas> vorlon: I don't see the same result. I see 3 RC bugs affecting so
urce packages with outdated binaries in squeeze
21:56 < lucas> vorlon: I think you clicked "sid", not "squeeze"
21:56 < vorlon> lucas: oh; I also told it to ignore 'outdated binaries in sid',
apparently this has a different effect than what I expected
21:57 < vorlon> lucas: I expected release=squeeze;outdatedsqueeze=ign;outdatedsi
d=ign to be equivalent to release=squeeze;outdatedsqueeze=ign
21:58 -!- giskard [~giskard@87-198-186-10.static.ptr.magnet.ie] has quit [Remote
host closed the connection]
21:58 -!- fcestrada (Fernando C. Estrada) [~fcestrada@189.216.124.12] has joined
#debian-devel
21:58 < vorlon> (i.e., why would I care about the presence of outdated binaries
in sid when asking only for bugs present in squeeze?)
22:01 < lucas> outdatedsid=ign ignores the source packages that have outdated bi
naries in sid. not necessarily the bugs that are present only because of outdate
d binaries (that info is not available)
22:05 -!- bandinia (Michele Baldessari) [~bandini@host247-5-dynamic.6-79-r.retai
l.telecomitalia.it] has joined #debian-devel
22:08 < _rene_> aurel32: so I need someone to explain it to me (basics suffice ;
))
22:08 -!- bandini [~bandini@host94-106-dynamic.16-79-r.retail.telecomitalia.it]
has quit [Ping timeout: 480 seconds]
22:09 -!- otavio (Otavio Salvador <otavio@debian.org>) [~otavio@189.114.111.55]
has joined #debian-devel
22:14 < aurel32> _rene_: from looking at the code and from my test
22:14 < aurel32> MALLOC_CHECK_ defaults to 3
22:14 < aurel32> which print the backtrace and do abort
22:15 < aurel32> MALLOC_CHECK_=2 simply abort, without printing the backtrace
22:15 < aurel32> so I don't really explain the behaviour from the bug report
22:15 < _rene_> exactly that's my confusion, too
22:16 < aurel32> except if ooo is actually calling a program, and can survive wi
th an abort, but not with an abort and a lot of data on stderr
22:16 < Q_> To 3? I run everything with 2 and see errors others don't see ...
22:16 < aurel32> really?
22:17 < Q_> As far as I know, yes.
22:17 < aurel32> #ifndef DEFAULT_CHECK_ACTION
22:17 < aurel32> #define DEFAULT_CHECK_ACTION 3
22:17 < aurel32> #endif
22:17 < aurel32> static int check_action = DEFAULT_CHECK_ACTION;
22:17 -!- Piet [~Piet__@7GDAAEN0C.tor-irc.dnsbl.oftc.net] has quit [Quit: Piet]
22:19 < aurel32> it has been changed from 1 to 3 in august 2004
22:19 < Q_> And does setting MALLOC_CHECK_ have any other effects?
22:19 -!- fcestrada [~fcestrada@189.216.124.12] has quit [Quit: Leaving.]
22:19 < waldi> (or traps SIGABRT ...)
22:20 < MadCoder> Q_: it's documented in malloc(1)
22:20 < Q_> waldi: Oh, I love applications that think they're smarter. I'm pretty sure oo.org is such.
22:20 < Rhonda> Q_: Noticed that the key isn't in the keyring - did sent the mes
22:21 < Q_> MadCoder: I know, it also says that settings it has an effect.
22:21 < waldi> Q_: well, applications catching SIGILL or SIGSEGV are not longer nice
22:21 < aurel32> Q_: if different than zero it basically detect the same things
22:22 < aurel32> Q_: just the resulting action is different depending on the actual value
22:22 < aurel32> abort, abort + message, etc.
22:24 -!- faw [~faw@faw.user.oftc.net] has quit [Read error: Connection reset by peer]
22:26 -!- Lethalman (Luca Bruno) [~lethal@host42-52-dynamic.51-79-r.retail.telecomitalia.it] has joined #debian-devel
22:28 < Q_> waldi: I know that some do catch SEGV and than call brk() or something.
22:28 < _rene_> OOo does do stuff with signals in its "system abstraction layer", yes. (though I've to look more closely what it does exactly)
22:28 < waldi> Q_: yeah, this is UB
22:29 < waldi> with ILL too
22:30 < aurel32> _rene_: strangely the backtrace shows a call to *c*free
22:30 < aurel32> which is specific SunOS
22:30 < aurel32> the glibc maps cfree to free to catch such cases
22:31 < aurel32> but maybe it does some strange things with memory allocation on sparc only
22:31 < Q_> Allocated with a different API? Like mixing new/malloc?
22:32 < aurel32> I don't know, maybe, or doing some assumption on how memory is allocated, and using a bit more than what has been allocated
22:32 < aurel32> I have no idea
22:32 < aurel32> but just find strange that cfree is called instead of free
22:36 < _rene_> at least I don't find it in the porting-relevant pieces of OOo...
22:37 < _rene_> (we don't use suns custom allocator anyway, but the system one). And if he's right that it worked half a year ago.... ;)
22:38 < aurel32> i don't know what he means by "randomly crashes"
22:38 < aurel32> he should precise how often
22:39 < aurel32> I am playing with OOo on sparc (sid version though)
22:39 < aurel32> and after 5 minutes it's still working
22:39 -!- faw (Felipe Augusto van de Wiel) [~faw@faye.complexopequenoprincipe.org.br] has joined #debian-devel
22:40 < _rene_> aurel32: it was reported against sids version, so.. :)
22:41 < _rene_> aurel32: if you would be so nice and could ask him in the bug I'd be grateful
apparently he didn't (yet), so relying.. :)
Grüße/Regards,
René
--
.''`. René Engelhard -- Debian GNU/Linux Developer
: :' : http://www.debian.org | http://people.debian.org/~rene/
`. `' rene@debian.org | GnuPG-Key ID: D03E3E70
`- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70
Reply to: