[12:29] <crimsun> asac: multiverse
[01:13] <gnomefreak> asac: ty
[01:13] <gnomefreak> asac: and yeah multiverse
[03:59] <Admiral_Chicago> gah sorry wrong channel
[09:14] <RR_qwerty> hello! Anybody here?
[11:21] <asac> hi
[11:24] <asac> hi
[11:27] <hjmf> hello
[11:31] <asac> lp is still SLOW
[11:31] <asac> yeah ... login succeeded;) took 45 seconds
[11:32] <hjmf> asac: what causes this error on retraces:
[11:32] <hjmf> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
[11:32] <hjmf> I'm getting it from time to time
[11:33] <asac> hmm
[11:33] <asac> i think its a corrupt stack
[11:33] <asac> sometimes crashes don't run in segfault
[11:33] <asac> when they access wrong memory
[11:33] <asac> but instead go ahead ... and the memory state get completely trashed
[11:33] <asac> and then you don't get a valuable backtrace out of it
[11:34] <hjmf> here is the last example: bug 90892
[11:34] <Ubugtu> Malone bug 90892 in firefox "[feisty]  Firefox Crashed " [Undecided,Needs info]  https://launchpad.net/bugs/90892
[11:35] <asac> hmm
[11:35] <asac> but that one is meaningful
[11:35] <asac> looks like realize bug
[11:35] <hjmf> TODO: learn about this stuff :-P
[11:36] <asac> its not that easy ... a backtrace is not always meaningful by definition as i said above
[11:37] <asac> when memory gets corrupted and process goes ahead things become meaningless
[11:37] <hjmf> I see
[11:37] <asac> output to console would be really important for us as well
[11:37] <asac> as mozilla prints assertions to console
[11:37] <asac> but we don't capture that by crash report i guess
[11:38] <hjmf> only if we ask the reporter for a re-crash
[11:38] <hjmf> but I guess that that is impossible for most of them
[11:39] <asac> yeah ... but often its not reproducible
[11:39] <asac> exactly
[11:39] <asac> often its not even obvious what causes this
[11:39] <asac> we had luck with the gtk_style_realize bugs that we had a testcase
[11:39] <asac> otherwise i could not have fixed this (e.g. not in totem)
[11:40] <hjmf> I see
[11:41] <hjmf> when I got time I have to take a look to some basic manuals about gdb and all this stuff to get a better idea
[11:42] <hjmf> I will
[11:43] <asac> damn is lp slow today ... maybe i should go bed again :)
[11:44] <asac> so how many dupes do we already have for bug 72018
[11:44] <Ubugtu> Malone bug 72018 in firefox "MASTER Firefox Crash [@gtk_style_realize]  [@nsFilePicker::Show] " [High,In progress]  https://launchpad.net/bugs/72018
[11:45] <hjmf> > 90
[11:45] <asac> yeah
[11:45] <asac> 96
[11:45] <asac> :)
[11:45] <asac> coolie
[11:45] <asac> i want 150
[11:45] <asac> then we can close :)
[11:46] <asac> i wonder if closing such a heavy weight bug causes karma to go up through sky ... or if its just the same because you already earned by marking duplicate
[11:47] <hjmf> ... I dont earn any karma at all
[11:47] <hjmf> jk
[11:47] <hjmf> btw bug 91067 is another dup?
[11:47] <Ubugtu> Malone bug 91067 in firefox "Firefox crashes after screen lock" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91067
[11:48] <hjmf> I don't see the nsFilePicker::Show call inside, but the retrace is almost the same than the one gnomefreak made in it
[11:48] <asac> its not important that ::Show is in call
[11:49] <asac> we just need gtk_style_realize ... now that we know that those are all the same
[11:49] <asac> bug just variants
[11:49] <asac> bug67886
[11:49] <asac> bug 67886
[11:49] <Ubugtu> Malone bug 67886 in firefox "Firefox crash when a gnome theme is selected" [Medium,In progress]  https://launchpad.net/bugs/67886
[11:49] <asac> that one can be merged with its duplicates into our grant master bug as well
[11:49] <asac> they are most likely the same issues
[11:49] <asac> hmm
[11:50] <asac> but maybe each single bug should be taken care first
[11:50] <hjmf> It's just that I did not see the MASTER's gtk issues marked as dups
[11:50] <asac> which?
[11:50] <asac> john merged them in afaik
[11:51] <hjmf> yes, my fault, I guess that I watched that yesterday or the day before, after gnomefreak's spam
[11:51] <hjmf> I guess that he was on duty
[11:52] <asac> ;)
[11:52] <hjmf> I did not check today (my fault) :)
[11:52] <asac> i would send a present to anyone who can tell me how to reproduce
[11:52] <asac> bug 90376
[11:52] <Ubugtu> Malone bug 90376 in firefox "Firefox https broken in some cases" [Undecided,Needs info]  https://launchpad.net/bugs/90376
[11:52] <asac> its in dapper only
[11:53] <asac> imo those folks have not restarted firefox properly
[11:53] <asac> but some swear they did
[11:53] <hjmf> I never had dapper
[11:53] <asac> so i am helpless
[11:54] <hjmf> but never happened to me such thing
[11:59] <hjmf> I have to go for a while
[11:59] <asac> bye ... will be out too soon
[12:14] <asac> gnomefreak: bug 45008 and its dupes are gtk_style_realize for us
[12:14] <Ubugtu> Malone bug 45008 in firefox "MASTER firefox theme crash" [High,Confirmed]  https://launchpad.net/bugs/45008
[12:28] <asac> i still wait for someone to come up with a crash like
[12:28] <asac> firefox crashing expectedly
[12:28] <asac> hehe ... they always use "firefox crashing unexpectedly" ... as if there might be expected crashes
[12:29] <asac> anyway, good to know that users might buy that a crash is a feature :)
[03:54] <gnomefreak> maybe a proxy issue with bug 90376? i will run some more tests i just wish i have 12+ links to use for testcase
[03:54] <Ubugtu> Malone bug 90376 in firefox "Firefox https broken in some cases" [Undecided,Needs info]  https://launchpad.net/bugs/90376
[04:12] <gnomefreak> for above bug im thinking extention issue (i have no extentions installed for dappers firefox) so i left comment on bug. bbl i have drs. appointment sort of
[08:55] <asac> gnomefreak: ok ... thanks for testing
[08:55] <asac> at least it does not happen to all ... so not "that" bad
[08:55] <asac> will be away till tomorrow ... a bit relaxing on weekend;)