(In reply to :dmajor from comment #16)
> (In reply to Chris Manchester (:chmanchester) from comment #15)
> > I'll take this. dmajor, does it seem worthwhile to explicitly check for the
> > clang 6 from automation case? Just disallowing clang-6 seems more
> > straightforward.
>
> So you're
(In reply to Mike Hommey [:glandium] (high latency) from comment #24)
> (In reply to Nathan Froyd [:froydnj] from comment #19)
> > (In reply to Mike Hommey [:glandium] (high latency) from comment #18)
> > > It's very possible this is the same as bug 1601707. If it is, we don't
> > > need to
(In reply to Mike Hommey [:glandium] (high latency) from comment #18)
> It's very possible this is the same as bug 1601707. If it is, we don't need
> to exclude clang 6.
OTOH, I don't want to be rediscovering that people are using a compiler
that doesn't implement some finer point of C++17 (bug
(In reply to Emilio Cobos Álvarez (:emilio) from comment #20)
> (In reply to Nathan Froyd [:froydnj] from comment #19)
> > (In reply to Mike Hommey [:glandium] (high latency) from comment #18)
> > > It's very possible this is the same as bug 1601707. If it is, we don't
> > > need to exclude clang
(In reply to Emilio Cobos Álvarez (:emilio) from comment #21)
> Maybe even tier 2 / running on m-c only, or something?
I'll just note that as somebody who has had multiple patches backed out
because of jobs that *only* run on central and those jobs aren't
selectable by default by `mach try fuzzy`
Comment on attachment 8626818
0001-Bug-833117-Replace-g_slice_set_config-with-G_SLICE-e.patch
Review of attachment 8626818:
-
Hooray for eliminating annoying startup messages.
::: xpcom/glue/standalone/nsXPCOMGlue.cpp
@@ +443,5 @@
Comment on attachment 8561105
Pad heap allocations passed to flag_qsort() on x86 Linux to work around gcc bug
affecting Ubuntu packages
Review of attachment 8561105:
-
Yuck. The #ifdef checks are correct, fwiw.
--
You received
(In reply to Karl Tomlinson (:karlt, offline til July 2) from comment #29)
Is there a reason you chose to use SA_RESTART? Not sure it makes much
difference in practice, but I would have expected an interrupt signal to try
to abort ASAP rather than restarting a system call.
I would expect that
Created attachment 618671
patch
Redirecting f? to karlt as bsmedberg suggests. Updated patch with
SIGQUIT handling as well.
I left SIGINT doing a eForceQuit; from comments in this bug, it sounds
like people start firefox from the command line and then C-c it. For
those sorts of usecases, it
(In reply to Benjamin Smedberg [:bsmedberg] from comment #15)
ok, fix it! I'd happily review a patch!
(In reply to Benjamin Smedberg [:bsmedberg] from comment #25)
I am not the right person to review this, having never written anything
useful with signal handlers.
I am confused. :)
If I
Created attachment 608074
patch
Here's a better, somewhat more verbose patch that doesn't require
anything beyond what we already use. When receiving SIG{INT,TERM} and
restarting, we now display about:home with an option to restore your
last session instead of the this is embarrassing page.
As
(In reply to Ted Mielczarek [:ted] from comment #19)
Breakpad doesn't handle SIGTERM, so you should be okay there. You will
probably need to make sure that your code interacts properly with the
profile locking code, since the purpose of that signal handler is to clean
up the profile lock
(In reply to Michael Wu [:mwu] from comment #22)
1. You should probably use nsAppStartup::Quit because it will do the Right
Things. This includes sending the proper shutdown notifications to code that
needs to clean up.
Mmm, good point.
2. Should probably make this generic enough to work on
Created attachment 609331
patch
New patch using nsIAppStartup; also fewer printfs.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/73536
Title:
MASTER Firefox crashes on instant X
Created attachment 607268
patch
Here's a patch which appears to DTRT on Linux. I don't have a Mac
machine and I even less familiar with the OS X event loop than I am with
the Linux one, so that bit would have to come from someone else.
--
You received this bug notification because you are a
Comment on attachment 607268
patch
Actually, this does the right thing, but it would drastically inflate
the version of GTK we require; g_unix_signal_add is said in the docs to
be available from 2.30 onwards (though this version isn't actually
available from the website...?), and we require 2.14.
16 matches
Mail list logo
