Guile 3.0.2 crashes with SIGBUS on x86_64 during 'guix pull'

  • Done
  • quality assurance status badge
Details
3 participants
  • Jakub Kądziołka
  • Ludovic Courtès
  • o.rojon
Owner
unassigned
Submitted by
o.rojon
Severity
important

Debbugs page

O
O
o.rojon wrote on 4 Jun 2020 12:12
The program '/gnu/store/foobar/compute-guix-derivation' failed to compute the derivation for guix
(name . Bug guix)(address . bug-guix@gnu.org)
54320f33124f0122ed56fb7e15b17ae4@posteo.net
Hello everyone,

on a freshly installed and reconfigured machine, I receive the following
error:
# guix pull: error: You found a bug: the program
'/gnu/store/kpxami25fi3mrxb37sfbbx2s366chpk5-compute-guix-derivation'
# failed to compute the derivation for Guix (version:
"790ada9168e0689c1c4607c61cdc1d2dbc327abf"; system: "x86_64-linux";
# host version: "398ec3c1e265a3f89ed07987f33b264db82e4080";
pull-version: 1).

I'm not entirely sure if, in this case, it is about RAM, as has been
mentioned in this thread: https://issues.guix.gnu.org/41710. I do have
24gb ram, but currently a small swap file, but that might be totally
unrelated.

If I can supply you with more information, please do not hesitate to
specify how I can aid fixing the issue.

Have a good day,
Olivier
L
L
Ludovic Courtès wrote on 4 Jun 2020 13:00
(address . o.rojon@posteo.net)(address . 41715@debbugs.gnu.org)
87sgfa7g9r.fsf@gnu.org
Hello,

o.rojon@posteo.net skribis:

Toggle quote (9 lines)
> on a freshly installed and reconfigured machine, I receive the
> following error:
> # guix pull: error: You found a bug: the program
> '/gnu/store/kpxami25fi3mrxb37sfbbx2s366chpk5-compute-guix-derivation'
> # failed to compute the derivation for Guix (version:
> "790ada9168e0689c1c4607c61cdc1d2dbc327abf"; system: "x86_64-linux";
> # host version: "398ec3c1e265a3f89ed07987f33b264db82e4080";
> pull-version: 1).

Is there more info above these lines?

I tried to reproduce it with:

guix time-machine --commit=398ec3c1e265a3f89ed07987f33b264db82e4080 \
-- time-machine --commit=790ada9168e0689c1c4607c61cdc1d2dbc327abf \
-- describe

but it works for me.

Toggle quote (5 lines)
> I'm not entirely sure if, in this case, it is about RAM, as has been
> mentioned in this thread: https://issues.guix.gnu.org/41710 . I do
> have 24gb ram, but currently a small swap file, but that might be
> totally unrelated.

24 GiB is more than enough.

Is the problem reproducible if you try again now?

Thanks for reporting the issue,
Ludo’.
J
J
Jakub Kądziołka wrote on 4 Jun 2020 15:15
Re: The program '/gnu/store/foobar/compute-guix-derivation' failed to compute the derivation for guix
(address . 41715@debbugs.gnu.org)
20200604221534.ctileqxszheqs22b@gravity
Hi,

I encountered a similar error message today, but it worked fine after
retrying. After digging around in /var/log/guix/drvs, I found these
lines in an appropriately-timestamped log file:

substitute: guix substitute: warning: ci.guix.gnu.org: connection failed: Connection timed out
@ build-started /gnu/store/klyq05c1q8jzwnwrlmvy4ma6m2h6hbk0-compute-guix-derivation.drv - x86_64-linux /var/log/guix/drvs/kl//yq05c1q8jzwnwrlmvy4ma6m2h6hbk0-compute-guix-derivation.drv.bz2 3907994
@ build-succeeded /gnu/store/klyq05c1q8jzwnwrlmvy4ma6m2h6hbk0-compute-guix-derivation.drv -

I do recall seeing the Connection timed out message, I'd even say it's
probably the reason why I decided to retry the pull without much
investigation.

Regards,
Jakub Kądziołka
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE5Xa/ss9usT31cTO54xWnWEYTFWQFAl7ZcoIACgkQ4xWnWEYT
FWQdQg/9GEQZomAp308YDv+xsp++RlUpZaiNO7dgaIHb/DGVdSAXAgHLyjpx6wA7
6QBfckB3hm+HERpKZFKLaE3qy2/l85Pe2gTicp8u/R3SPI5ScVLYelEuNJNxxoQM
JN9wauaDuHlfd52LPwu5geAbhMJJ2Ra7/+HE3GtT0+sQdCaZSbp0+uo75sA9566q
5D7lOjwHLTbzYRSN0kp9vVlYikleaBQD9x5702vwmcmwaV1R0EQVnwV7YnOHwWh8
BIokB/jdWZIW//DkGmySdLqJIvpxulLY88RutWO1IMMNI2MnURxW6u60SL/yNQWt
tx82D6mOcn7hKWjhnBfA9KEZoBkrzumIkJLfXHNv/De2qaEB3VOYJKo6qK9+yyuW
VLcZcJ837d+CUgeD3OpkIFLsF5PCgMjmCnhaysTdbNnb4DZg7xv+uVqSNY8qH4mv
17swJFRaKCEmcypOmHZ2Tn2Dbsz6JbpoHVj/BDbeameMRiBIaEI4hh/SDO0sxeGf
MrV9i0ebQNb4EGWvzI7zMNyo2JmMJ5NdaZu0Rf54woIxhC7CMXEKZio29h1YNYKN
fce6GQ+LQKgCayRzKuVi8mZC7O9onf6bgU1CQe5YyuKcCJZSojYhXKmcHhpx0YC5
wVxWBqZSmFNsPBuNuQFNOMl3hLuzqpln3j7x2PvZzMxQ+zhn/Uk=
=QACt
-----END PGP SIGNATURE-----


O
O
o.rojon wrote on 4 Jun 2020 22:54
Re: bug#41715: The program '/gnu/store/foobar/compute-guix-derivation' failed to compute the derivation for guix
(name . Ludovic Courtès)(address . ludo@gnu.org)
3b6810281efe6055d52232975fd44c91@posteo.net
Hej Ludo,

thanks for the quick reply!

I just tried to pull again and yielded the same result.

Actually, no, there is nothing above these lines. Yet, let me copy/paste
the whole command in/output. It is in german but I guess the steps are
so common by now that it shouldnt be a problem to understand :)

# user@computer ~$ guix pull
# Kanal „guix“ wird vom Git-Repository auf
# Von diesen Kanälen wird erstellt:
# guix pull: error: You found a bug: the program
'/gnu/store/kpxami25fi3mrxb37sfbbx2s366chpk5-compute-guix-derivation'
# failed to compute the derivation for Guix (version:
"0713929685d2fd1970df1b1ce238ee7bd6e892f8"; system: "x86_64-linux";
# host version: "398ec3c1e265a3f89ed07987f33b264db82e4080";
pull-version: 1).
# Please report it by email to <bug-guix@gnu.org>.

Also, now I am sure it has nothing to do with ram. Apart from the
already available ram, I resized my swapdevice.

Is there anything else I should test? One thing I could do is to
roll-back (I did a upgrade/reconfigure cycle after installation). Should
I do that and then pull again?

Greetings,
Olivier

On 04.06.2020 22:00, Ludovic Courtès wrote:
Toggle quote (34 lines)
> Hello,
>
> o.rojon@posteo.net skribis:
>
>> on a freshly installed and reconfigured machine, I receive the
>> following error:
>> # guix pull: error: You found a bug: the program
>> '/gnu/store/kpxami25fi3mrxb37sfbbx2s366chpk5-compute-guix-derivation'
>> # failed to compute the derivation for Guix (version:
>> "790ada9168e0689c1c4607c61cdc1d2dbc327abf"; system: "x86_64-linux";
>> # host version: "398ec3c1e265a3f89ed07987f33b264db82e4080";
>> pull-version: 1).
>
> Is there more info above these lines?
>
> I tried to reproduce it with:
>
> guix time-machine --commit=398ec3c1e265a3f89ed07987f33b264db82e4080 \
> -- time-machine --commit=790ada9168e0689c1c4607c61cdc1d2dbc327abf \
> -- describe
>
> but it works for me.
>
>> I'm not entirely sure if, in this case, it is about RAM, as has been
>> mentioned in this thread: https://issues.guix.gnu.org/41710 . I do
>> have 24gb ram, but currently a small swap file, but that might be
>> totally unrelated.
>
> 24 GiB is more than enough.
>
> Is the problem reproducible if you try again now?
>
> Thanks for reporting the issue,
> Ludo’.
O
O
o.rojon wrote on 5 Jun 2020 01:26
(name . Ludovic Courtès)(address . ludo@gnu.org)
6a6c6f638f0a33ec39b9e70843090299@posteo.net
Just to follow up: a roll-back does NOT solve the issue.

What I have tried:
1) roll-back via guix system roll-back (to the generation that was
created upon system installation)
2) roll-back via guix package --roll-back (same)
3) (1) + (2) combined
4) boot into the generation created upon system installation.

In none of these cases was I able to run 'guix pull'.

Does it help for you to see my system configuration file? Because there
isnt much in there apart from very basic packages (ncdu, recutils, some
fonts, some icon packs) and a few services (GDM->SDDM login manager,
MATE desktop, TOR). Also note that before the re-installation, I have
not experienced problems with this configuration (MINUS mate desktop and
TOR).

On 04.06.2020 22:00, Ludovic Courtès wrote:
Toggle quote (34 lines)
> Hello,
>
> o.rojon@posteo.net skribis:
>
>> on a freshly installed and reconfigured machine, I receive the
>> following error:
>> # guix pull: error: You found a bug: the program
>> '/gnu/store/kpxami25fi3mrxb37sfbbx2s366chpk5-compute-guix-derivation'
>> # failed to compute the derivation for Guix (version:
>> "790ada9168e0689c1c4607c61cdc1d2dbc327abf"; system: "x86_64-linux";
>> # host version: "398ec3c1e265a3f89ed07987f33b264db82e4080";
>> pull-version: 1).
>
> Is there more info above these lines?
>
> I tried to reproduce it with:
>
> guix time-machine --commit=398ec3c1e265a3f89ed07987f33b264db82e4080 \
> -- time-machine --commit=790ada9168e0689c1c4607c61cdc1d2dbc327abf \
> -- describe
>
> but it works for me.
>
>> I'm not entirely sure if, in this case, it is about RAM, as has been
>> mentioned in this thread: https://issues.guix.gnu.org/41710 . I do
>> have 24gb ram, but currently a small swap file, but that might be
>> totally unrelated.
>
> 24 GiB is more than enough.
>
> Is the problem reproducible if you try again now?
>
> Thanks for reporting the issue,
> Ludo’.
L
L
Ludovic Courtès wrote on 5 Jun 2020 09:29
(address . o.rojon@posteo.net)(address . 41715@debbugs.gnu.org)
87mu5h1noe.fsf@gnu.org
Hi,

o.rojon@posteo.net skribis:

Toggle quote (11 lines)
> Just to follow up: a roll-back does NOT solve the issue.
>
> What I have tried:
> 1) roll-back via guix system roll-back (to the generation that was
> created upon system installation)
> 2) roll-back via guix package --roll-back (same)
> 3) (1) + (2) combined
> 4) boot into the generation created upon system installation.
>
> In none of these cases was I able to run 'guix pull'.

Thanks for testing this.

Note that, if “which guix” returns ~/.config/guix/current/bin/guix, then
none of the rollbacks above can have any effect. What could make a
difference (but again, that would seem weird to me) is:

guix pull --roll-back

Are you passing extra options to guix-daemon, such as
‘--cache-failures’? Or did you enable offloading?

It could also be that a transient failure is causing a silent build
failure somewhere, as Jakub suggests.

Thanks,
Ludo’.

PS: Please keep the bug address Cc’d.
O
O
o.rojon wrote on 5 Jun 2020 17:57
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 41715@debbugs.gnu.org)
97da9eb75628d48de3b8ef4abb212bca@posteo.net
Hi Ludo,

guix pull --roll-back did not solve the issue. The only thing I believe
to have changed is the "host version" portion of the error message.

'which guix' actually points to ~/.configu/guix/current/bin/guix. Should
this command yield a different value?

I have actually not done anything regarding either guix-daemon or
offloading. The only things I did after the fresh install were a
reconfigure and passing a manifest file to 'guix package -m'.

I may have misunderstood what Jakub wrote because I am unsure what a
transient failure is. The portion I believe to have understood
essentially says "try again later and it should work".

I found the logs of 'compute-guix-derivation', but I was unable to see
anything meaningful opening the .drv.bz2 file in emacs. Am I doing
something wrong?

I wont be on my guix machine for some days now but appreciate pointers.
:)

Olivier

On 05.06.2020 18:29, Ludovic Courtès wrote:
Toggle quote (34 lines)
> Hi,
>
> o.rojon@posteo.net skribis:
>
>> Just to follow up: a roll-back does NOT solve the issue.
>>
>> What I have tried:
>> 1) roll-back via guix system roll-back (to the generation that was
>> created upon system installation)
>> 2) roll-back via guix package --roll-back (same)
>> 3) (1) + (2) combined
>> 4) boot into the generation created upon system installation.
>>
>> In none of these cases was I able to run 'guix pull'.
>
> Thanks for testing this.
>
> Note that, if “which guix” returns ~/.config/guix/current/bin/guix,
> then
> none of the rollbacks above can have any effect. What could make a
> difference (but again, that would seem weird to me) is:
>
> guix pull --roll-back
>
> Are you passing extra options to guix-daemon, such as
> ‘--cache-failures’? Or did you enable offloading?
>
> It could also be that a transient failure is causing a silent build
> failure somewhere, as Jakub suggests.
>
> Thanks,
> Ludo’.
>
> PS: Please keep the bug address Cc’d.
L
L
Ludovic Courtès wrote on 7 Jun 2020 12:47
(address . o.rojon@posteo.net)(address . 41715@debbugs.gnu.org)
87pnaasloq.fsf@gnu.org
Hi,

o.rojon@posteo.net skribis:

Toggle quote (4 lines)
> guix pull --roll-back did not solve the issue. The only thing I
> believe to have changed is the "host version" portion of the error
> message.

OK, that’s expected.

Toggle quote (4 lines)
> 'which guix' actually points to
> ~/.configu/guix/current/bin/guix. Should this command yield a
> different value?

No.

Toggle quote (8 lines)
> I have actually not done anything regarding either guix-daemon or
> offloading. The only things I did after the fresh install were a
> reconfigure and passing a manifest file to 'guix package -m'.
>
> I may have misunderstood what Jakub wrote because I am unsure what a
> transient failure is. The portion I believe to have understood
> essentially says "try again later and it should work".

Yes, that’s the essence of it. :-)

Toggle quote (4 lines)
> I found the logs of 'compute-guix-derivation', but I was unable to see
> anything meaningful opening the .drv.bz2 file in emacs. Am I doing
> something wrong?

Could you try this:

strace -s 500 -o log guix pull

and post the ‘log’ file, compressed, somewhere?

Thanks,
Ludo’.
O
O
o.rojon wrote on 8 Jun 2020 07:55
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 41715@debbugs.gnu.org)
e1fcc66a4a7d5f89e7135e0459ead070@posteo.net
Hi Ludo,

here is the log uploaded on mediafire:
you can recommend another uploading service, feel free to!)

Since the log is in german, let me specify at least two of the recurrent
phrases in english:
"Datei oder Verzeichnis nicht gefunden" means "file or directory not
found"
"Die Ressource ist zur Zeit nicht verfügbar" means "Resource is
currently unavailable"

If there is other things that need be translated, dont hesitate to tell
me :)

Greetings,
Olivier

On 07.06.2020 21:47, Ludovic Courtès wrote:
Toggle quote (38 lines)
> Hi,
>
> o.rojon@posteo.net skribis:
>
>> guix pull --roll-back did not solve the issue. The only thing I
>> believe to have changed is the "host version" portion of the error
>> message.
>
> OK, that’s expected.
>
>> 'which guix' actually points to
>> ~/.configu/guix/current/bin/guix. Should this command yield a
>> different value?
>
> No.
>
>> I have actually not done anything regarding either guix-daemon or
>> offloading. The only things I did after the fresh install were a
>> reconfigure and passing a manifest file to 'guix package -m'.
>>
>> I may have misunderstood what Jakub wrote because I am unsure what a
>> transient failure is. The portion I believe to have understood
>> essentially says "try again later and it should work".
>
> Yes, that’s the essence of it. :-)
>
>> I found the logs of 'compute-guix-derivation', but I was unable to see
>> anything meaningful opening the .drv.bz2 file in emacs. Am I doing
>> something wrong?
>
> Could you try this:
>
> strace -s 500 -o log guix pull
>
> and post the ‘log’ file, compressed, somewhere?
>
> Thanks,
> Ludo’.
L
L
Ludovic Courtès wrote on 9 Jun 2020 07:30
(address . o.rojon@posteo.net)(address . 41715@debbugs.gnu.org)
87mu5cia64.fsf@gnu.org
Hi,

o.rojon@posteo.net skribis:

Toggle quote (4 lines)
> here is the log uploaded on mediafire:
> http://www.mediafire.com/file/ldqoi68y88rzrn9/log.bz2/file (note that
> if you can recommend another uploading service, feel free to!)

I don’t know, maybe you could run IPFS.

The log reads:

Toggle snippet (7 lines)
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f3d44cfee50) = 1498
close(17) = 0
read(16, "", 1) = 0
close(16) = 0
wait4(1498, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGBUS}], 0, NULL) = 1498

… which means the ‘compute-guix-derivation’ process crashed with SIGBUS.

Could you run:

ulimit -c unlimited
guix pull

That should fail again, but this time there should be a ‘core’ file in
the current directory (or ‘core.’ followed by digits).

Then you can run:

gdb --core=./core

and at the GDB prompt, type:

thread apply all bt

Could you let me know what that returns?

Thanks,
Ludo’.
O
O
o.rojon wrote on 11 Jun 2020 22:54
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 41715@debbugs.gnu.org)
47c4e596596303893a847212ffa4da9b@posteo.net
Hej Ludo,

crazy, I wouldn't have thought it would go as deep as gdb as quickly ;-)

I followed the steps you mentioned, the results you find here:
only part I omitted from the gdb output is the first lines mentioned the
license. (Will look at IPFS, maybe next time :))

If you need anything else, dont hesitate to specify. Also, should a
reinstall become necessary, that would be annoying but not the end of
the world. So if we hit a dead end thats fine by me.

Thanks a lot for your help. So far, I received only good from the guix
community :)

Greetings,
Olivier

On 09.06.2020 16:30, Ludovic Courtès wrote:
Toggle quote (46 lines)
> Hi,
>
> o.rojon@posteo.net skribis:
>
>> here is the log uploaded on mediafire:
>> http://www.mediafire.com/file/ldqoi68y88rzrn9/log.bz2/file (note that
>> if you can recommend another uploading service, feel free to!)
>
> I don’t know, maybe you could run IPFS.
>
> The log reads:
>
> --8<---------------cut here---------------start------------->8---
> clone(child_stack=NULL,
> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
> child_tidptr=0x7f3d44cfee50) = 1498
> close(17) = 0
> read(16, "", 1) = 0
> close(16) = 0
> wait4(1498, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGBUS}], 0, NULL) =
> 1498
> --8<---------------cut here---------------end--------------->8---
>
> … which means the ‘compute-guix-derivation’ process crashed with
> SIGBUS.
>
> Could you run:
>
> ulimit -c unlimited
> guix pull
>
> That should fail again, but this time there should be a ‘core’ file in
> the current directory (or ‘core.’ followed by digits).
>
> Then you can run:
>
> gdb --core=./core
>
> and at the GDB prompt, type:
>
> thread apply all bt
>
> Could you let me know what that returns?
>
> Thanks,
> Ludo’.
L
L
Ludovic Courtès wrote on 12 Jun 2020 07:12
(address . o.rojon@posteo.net)(address . 41715@debbugs.gnu.org)
87zh9874q9.fsf@gnu.org
Hi Olivier,

o.rojon@posteo.net skribis:

Toggle quote (5 lines)
> I followed the steps you mentioned, the results you find here:
> https://www.mediafire.com/file/g5yz8f3pput8f3w/gdb-output/file . The
> only part I omitted from the gdb output is the first lines mentioned
> the license. (Will look at IPFS, maybe next time :))

Since it’s a small file, you can send it as an attachment.

GDB shows:

Toggle snippet (20 lines)
Core was generated by `/gnu/store/0m0vd873jp61lcm4xa3ljdgx381qa782-guile-3.0.2/bin/guile --no-auto-com'.
Program terminated with signal SIGBUS, Bus error.
#0 0x00007f90885ccc78 in ?? ()
[Current thread is 1 (LWP 845)]
(gdb) thread apply all bt

Thread 9 (LWP 853):
#0 0x00007f90884d90a4 in ?? ()
#1 0x0000000000000001 in ?? ()
#2 0x0000000000000001 in ?? ()
#3 0x00007f90840c9a30 in ?? ()
#4 0x00007f90840c95a0 in ?? ()
#5 0x00007f90840ca700 in ?? ()
#6 0x00007f90885ac067 in ?? ()
#7 0x00007f90845efa80 in ?? ()
#8 0x00007f90884fed94 in ?? ()
#9 0x0000000000000001 in ?? ()
#10 0x00007f90840c95a0 in ?? ()

That means debugging info is lacking. To address that, could you run:

guix build $(guix gc --derivers /gnu/store/0m0vd873jp61lcm4xa3ljdgx381qa782-guile-3.0.2)

and then:

echo 'set debug-file-directory /gnu/store/9lg4gssswn2cwn54p6jjy6nld16ah795-guile-3.0.2-debug/lib/debug' >> ~/.gdbinit

At that point, you can try again to run:

gdb --core=./core

That will hopefully show more useful info.

Thanks in advance!

Ludo’.
L
L
Ludovic Courtès wrote on 17 Jun 2020 05:06
control message for bug #41715
(address . control@debbugs.gnu.org)
87o8phrj57.fsf@gnu.org
retitle 41715 Guile 3.0.2 crashes with SIGBUS on x86_64 during 'guix pull'
quit
L
L
Ludovic Courtès wrote on 17 Jun 2020 05:06
(address . control@debbugs.gnu.org)
87mu51rj50.fsf@gnu.org
severity 41715 important
quit
O
O
Olivier wrote on 21 Jul 2020 11:11
Re: bug#41715: The program '/gnu/store/foobar/compute-guix-derivation' failed to compute the derivation for guix
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 41715@debbugs.gnu.org)
bdbdae03-ed6d-3c1d-34b0-311efb4b7f94@posteo.net
Hej Ludo,

I see that some time has passed and I believe that the issue can be closed.

Long story short, my hdd has died and I bought a new one and
re-installed. I could imagine that the errors I was running into were
related to the impending hardware failure -- that's a speculation,
though. Anyway, following your suggestions brought me to the same point
I was at earlier (gdb didnt show anything useful).

Another possible source of error I have not mentioned before (I simply
forgot about it): after the fresh install, I swapped the swap and /home
partition using another OS (I have two hdds, each of which has a
different OS). I don't know if that could've been the problem and/or one
reason the hdd died.

Anyway, I'm thankful for your supportive attitude and your time.

Have a good day,

Olivier

Am 12.06.20 um 16:12 schrieb Ludovic Courtès:
Toggle quote (50 lines)
> Hi Olivier,
>
> o.rojon@posteo.net skribis:
>
>> I followed the steps you mentioned, the results you find here:
>> https://www.mediafire.com/file/g5yz8f3pput8f3w/gdb-output/file . The
>> only part I omitted from the gdb output is the first lines mentioned
>> the license. (Will look at IPFS, maybe next time :))
> Since it’s a small file, you can send it as an attachment.
>
> GDB shows:
>
> --8<---------------cut here---------------start------------->8---
> Core was generated by `/gnu/store/0m0vd873jp61lcm4xa3ljdgx381qa782-guile-3.0.2/bin/guile --no-auto-com'.
> Program terminated with signal SIGBUS, Bus error.
> #0 0x00007f90885ccc78 in ?? ()
> [Current thread is 1 (LWP 845)]
> (gdb) thread apply all bt
>
> Thread 9 (LWP 853):
> #0 0x00007f90884d90a4 in ?? ()
> #1 0x0000000000000001 in ?? ()
> #2 0x0000000000000001 in ?? ()
> #3 0x00007f90840c9a30 in ?? ()
> #4 0x00007f90840c95a0 in ?? ()
> #5 0x00007f90840ca700 in ?? ()
> #6 0x00007f90885ac067 in ?? ()
> #7 0x00007f90845efa80 in ?? ()
> #8 0x00007f90884fed94 in ?? ()
> #9 0x0000000000000001 in ?? ()
> #10 0x00007f90840c95a0 in ?? ()
> --8<---------------cut here---------------end--------------->8---
>
> That means debugging info is lacking. To address that, could you run:
>
> guix build $(guix gc --derivers /gnu/store/0m0vd873jp61lcm4xa3ljdgx381qa782-guile-3.0.2)
>
> and then:
>
> echo 'set debug-file-directory /gnu/store/9lg4gssswn2cwn54p6jjy6nld16ah795-guile-3.0.2-debug/lib/debug' >> ~/.gdbinit
>
> At that point, you can try again to run:
>
> gdb --core=./core
>
> That will hopefully show more useful info.
>
> Thanks in advance!
>
> Ludo’.
L
L
Ludovic Courtès wrote on 22 Jul 2020 03:12
(name . Olivier)(address . o.rojon@posteo.net)(address . 41715@debbugs.gnu.org)
87eep3kge6.fsf@gnu.org
Hi Olivier,

Olivier <o.rojon@posteo.net> skribis:

Toggle quote (8 lines)
> I see that some time has passed and I believe that the issue can be closed.
>
> Long story short, my hdd has died and I bought a new one and
> re-installed. I could imagine that the errors I was running into were
> related to the impending hardware failure -- that's a speculation,
> though. Anyway, following your suggestions brought me to the same
> point I was at earlier (gdb didnt show anything useful).

OK, too bad.

Do let us know if you experience a similar crash again.

Thank you,
Ludo’.
L
L
Ludovic Courtès wrote on 11 Oct 2020 07:37
control message for bug #41715
(address . control@debbugs.gnu.org)
87eem4g776.fsf@gnu.org
tags 41715 unreproducible
close 41715
quit
?
Your comment

This issue is archived.

To comment on this conversation send an email to 41715@patchwise.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 41715
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch