unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: raingloom <raingloom@riseup.net>
To: Mark H Weaver <mhw@netris.org>
Cc: 43610@debbugs.gnu.org
Subject: bug#43610: IceCat segfault
Date: Sun, 27 Sep 2020 07:49:37 +0200	[thread overview]
Message-ID: <20200927074937.3b23c327@riseup.net> (raw)
In-Reply-To: <87blhs8lb7.fsf@netris.org>

On Sat, 26 Sep 2020 14:05:53 -0400
Mark H Weaver <mhw@netris.org> wrote:

> Hi,
> 
> raingloom <raingloom@riseup.net> writes:
> > It crashed immediately without any visible activity.  
> 
> Okay.
> 
> > It does start up properly with a fresh profile. I'll try to bisect
> > the addons list later.  
> 
> In the meantime, to start IceCat 78 with your existing profile but
> with addons temporarily disabled, try running:
> 
>   icecat -safe-mode
> 
> That should allow you to recover your existing bookmarks, history,
> cookies, saved passwords, tabs, etc.  Then you can try adding back
> your preferred addons incrementally to find out which one is causing
> the problem.

It still crashes with the -safe-mode flag. Luckily I keep most things
outside modern browsers, so it's not a huge loss. (For obvious reasons
I do not consider them reliable.)

> > Tbh this would be a good time to have a debug output for IceCat on
> > hand.  
> 
> While I acknowledge that it might occasionally be useful in edge cases
> like this, it would also dramatically increase the memory requirements
> at build time.  For what it's worth, in the ~6 years that I've been
> maintaining the IceCat package in Guix, I don't recall being asked
> for a debug output before now.
> 
> I'm particularly sensitive to the memory requirements at build time,
> because I choose not to trust the build farm and therefore to build my
> entire Guix system with GNOME from source code on a relatively old
> Thinkpad X200 with only 4 GB of RAM.  I've been doing this for many
> years, and I'd like to enable other Guix users to do so if they wish.
> 
> My impression is that IceCat debug outputs would primarily useful to
> people who are actively developing IceCat, in which case it makes more
> sense to build it manually to allow incremental rebuilds after
> modifying the source code.
> 
> If it turns out that there's more interest in IceCat debug outputs
> than I've anticipated (others: please speak up if you need this!),
> I'm not necessarily opposed to adding them, but someone with a more
> powerful machine would need to take over maintenance of our IceCat
> package, because I would be unable to locally test the official build.
> 
> What do you think?  Do other people need IceCat 'debug' outputs?
> 
>       Thanks,
>         Mark


Huh, I was not aware that it increased build time memory requirements.
I assumed it just gets sent to the void in the 'strip phase, just like
it is in other packages.
Maybe feature flags could help with this in the future. Since
(hopefully) nothing depends on IceCat, the build farm could just build
it with debug symbols, and those who want to build it locally can
build it without them. But that's off topic for this thread.
Local builds are definitely cool. As a fellow 4 gigger/thinkpadder I
appreciate anything that lets me build things locally without 16+ gigs
of swap. (you might think that's an exaggeration, but then you haven't
tried to build Idris 2 with Idris 1.)




  reply	other threads:[~2020-09-27  5:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-25 13:26 bug#43610: IceCat segfault raingloom
2020-09-25 16:11 ` Mark H Weaver
2020-09-26  2:34   ` raingloom
2020-09-26 18:05     ` Mark H Weaver
2020-09-27  5:49       ` raingloom [this message]
2020-09-27 20:36         ` Mark H Weaver
2020-10-01 22:57           ` raingloom
2020-10-01 23:28             ` raingloom
2020-10-09  7:42               ` Ricardo Wurmus
2020-11-30 20:06                 ` Ricardo Wurmus
2020-11-30 20:12                   ` Ricardo Wurmus
2020-12-13 18:19               ` Alex ter Weele
2020-12-15 11:24                 ` Ludovic Courtès
2022-07-11 18:38                   ` Maxim Cournoyer
2020-10-01  1:56       ` Mike Gerwitz
2023-04-07 16:14 ` bug#43610: Segfault still an issue Dominik Delgado via Bug reports for GNU Guix
2023-04-08  7:55 ` Dominik Delgado via Bug reports for GNU Guix

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200927074937.3b23c327@riseup.net \
    --to=raingloom@riseup.net \
    --cc=43610@debbugs.gnu.org \
    --cc=mhw@netris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).