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 [[email protected]] 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 [[email protected]] has quit [Remote host closed the connection] 21:58 -!- fcestrada (Fernando C. Estrada) [[email protected]] 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) [[email protected] 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 [[email protected]] has quit [Ping timeout: 480 seconds] 22:09 -!- otavio (Otavio Salvador <[email protected]>) [[email protected]] 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 [[email protected]] 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 [[email protected]] 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 [[email protected]] has quit [Read error: Connection reset by peer] 22:26 -!- Lethalman (Luca Bruno) [[email protected]] 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) [[email protected]] 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/ `. `' [email protected] | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
