zypper segfaulting

Starting yesterday and continuing today “zypper dup” is crashing with a simple message of “Segmentation fault” during the process of downloading packages. Restarting the “zypper dup” process continues the downloads. Th installation after all the packages are successfully downloaded has not crashed. Yesterday it crashed three times, while today only once (though there were more packages to download yesterday).

Is anyone else seeing this?

Not me, FWIW. Which makes me wonder about your repos. Please show


zypper lr -d

between CODE tags, the # in the editor.

Are you sure it’s during a download?
I’ve noticed that sometimes packages install immediately after a download, other times install happens only after all downloading has completed.

It’s more likely that a segmentation fault would happen during an install than a download… Or, at least I can’t think of a reason why it can happen during a download.

Inspecting your system log can provide a more informative error,
Assuming the segmentation fault isn’t so serious it causes your system to crash, you can view your system log in real time while you’re doing any suspect activity

journalctl -f

TSU

Yes. It just happened.


Retrieving package libgcj-jar-gcc6-6.5.0-1.15.x86_64
                                          (1/89),   9.8 MiB ( 10.8 MiB unpacked)
Retrieving: libgcj-jar-gcc6-6.5.0-1.15.x86_64.rpm ............[done (1.4 MiB/s)]
Retrieving package glibc-2.29-3.1.x86_64  (2/89),   1.7 MiB (  6.5 MiB unpacked)
Retrieving: glibc-2.29-3.1.x86_64.rpm ......................[done (666.1 KiB/s)]
Retrieving package glibc-32bit-2.29-3.1.x86_64
                                          (3/89),   1.4 MiB (  4.1 MiB unpacked)
Retrieving: glibc-32bit-2.29-3.1.x86_64.rpm --------------------------[starting]Segmentation fault (core dumped)

Something may have been broken in the 20190305 update. The segfault was when downloading for the 20190307 update.

I’ve seen zypper dup silently exit 2 or 3 times while downloading – with no seg fault, no message, nothing in dmesg. It just stops at some random percentage of an rpm (not between rpms) and returns to the command line.

I will be completely honest, I am not sure when it’s happening (I did edit the log file down by slimming down my “PC name” in the log … it’s now 2.7MB

It usually happens after you go through the full install and setup and it is downloading/installing stuff

I am having another issue with lagginess on Gnome when no other Gnome on this same machine does this … SO I MAY redo this as Plasma 5 … IF the same issue happens (the ORIGINAL ISSUE) then I will be able to save more logs of what happened this time … if not i still have the log from the Gnome install so maybe (hypothetically thinking…) it’s something with one of the Gnome packages

I am off to read through the log (again of the original issue) again right now

sorry … posted my last message on the wrong thread … i will remove (I think i see there is a time limit before i can delete the post) that post and THIS one too when i can … sorry again

I’ve experienced silent exit, but with nothing to indicate so except that nothing more is written on the duping screen, and not in a while, since I’ve done little updating in the past week or two.

I’ve done a few TW upgrades within this past week and haven’t seen any problems,

Long ago, I experienced many “silent exits” usually during especially long updates/upgrades, but none that I can remember that actually displayed a segmentation fault. And, in all cases I can remember vaguely from long ago, I didn’t have to wait, I just restarted the update/upgrade and the problem would iron itself out.

Since @nrickert reports he has experienced the problem as described, I guess it exists but I cannot think how how such a thing can happen.

TSU

I have seen this a couple of times with the last few updates. It occurs during the download. Once restarting progressed a little further and then had to be restarted again. The other time it completed on a single restart. I have since done a

sudo rpm --rebuilddb && sudo zypper clean -a && sudo zypper ref

I’m now waiting for a big update to see if it occurs again.

On 3/8/19 12:16 PM, poorboywilly wrote:
>
> Starting yesterday and continuing today “zypper dup” is crashing with a
> simple message of “Segmentation fault” during the process of downloading
> packages. Restarting the “zypper dup” process continues the downloads.
> Th installation after all the packages are successfully downloaded has
> not crashed. Yesterday it crashed three times, while today only once
> (though there were more packages to download yesterday).
>
> Is anyone else seeing this?
>
>

I’m seeing this also. I only have non-oss - oss - update and packman
enabled.


Ken
unix since 1986
S.u.S.E.-openSUSE since 1998

On 3/8/19 2:56 PM, xmetal wrote:
>
> tsu2;2896474 Wrote:
>> Are you sure it’s during a download?
>> I’ve noticed that sometimes packages install immediately after a
>> download, other times install happens only after all downloading has
>> completed.
>>
>> It’s more likely that a segmentation fault would happen during an
>> install than a download… Or, at least I can’t think of a reason why it
>> can happen during a download.
>>
>> Inspecting your system log can provide a more informative error,
>> Assuming the segmentation fault isn’t so serious it causes your system
>> to crash, you can view your system log in real time while you’re doing
>> any suspect activity
>>>
> Code:
> --------------------
> > > journalctl -f
> --------------------
>>>
>>
>> TSU
>
>
> I will be completely honest, I am not sure when it’s happening (I did
> edit the log file down by slimming down my “PC name” in the log … it’s
> now 2.7MB
>
> It usually happens after you go through the full install and setup and
> it is downloading/installing stuff
>
> I am having another issue with lagginess on Gnome when no other Gnome on
> this same machine does this … SO I MAY redo this as Plasma 5 … IF
> the same issue happens (the ORIGINAL ISSUE) then I will be able to save
> more logs of what happened this time … if not i still have the log
> from the Gnome install so maybe (hypothetically thinking…) it’s
> something with one of the Gnome packages
>
> I am off to read through the log (again of the original issue) again
> right now
>
>

I always use

Code:

zypper -v dup -d

before running dup and I am getting the segfault, So it is happening
during the download phase.


Ken
unix since 1986
S.u.S.E.-openSUSE since 1998

I am seeing this as well.

2 different boxes.

Box 1: Ryzen 1700X machine, 16 GB ram

Box 2: AMD APU, 8G ram

It’s a bug in curl.

https://build.opensuse.org/request/show/682978

https://bugzilla.opensuse.org/show_bug.cgi?id=1127849

Hi
See https://bugzilla.opensuse.org/show_bug.cgi?id=1127849 and https://build.opensuse.org/request/show/682978

not related to my other post but I found an ISO that was newer than the one i had been having issues with (march 2019) and used the November 2018 ISO for TW I found and while this time the install works just fine

I NOW am seeing a segment fault when using zypper

using the following command did not help
sudo rpm --rebuilddb && sudo zypper clean -a && sudo zypper ref

right now i cant update or install anything without getting right back to that segment fault when downloading

I have gotten the segfault on two different machines while packages are installing. Never appears to be the same package in 4 attempts (twice on each machine). Come to think of it: I also got the exit during a download but restarting zypper dup finished the download and gave the segfault during installation.

I hate to cross post but i wonder if THIS is the same thing happening in my other thread where the installer for the new snapshots fail exit for no reason … it could be the same issue I guess … zypper dup on an installed rig = exits … the other issue i had = installer exits during the install

anyway rerunning sudo zypper dup EVERY TIME it segment faults, gets more and more package downloaded

dmesg | grep segfault 

got me this
**
538.121244] zypper[3594]: segfault at 100000228 ip 00007fb985d01237 sp 00007fff45beded0 error 4 in libcurl.so.4.5.0[7fb985cbb000+63000]
890.537248] zypper[4124]: segfault at 7f83000001f9 ip 00007f83507b15e1 sp 00007ffd6ae09ac8 error 6 in libcurl.so.4.5.0[7f8350785000+63000]
2950.791449] zypper[8081]: segfault at 0 ip 00007fe7f6f3450e sp 00007ffcfe64f0e0 error 4 in libc-2.29.so[7fe7f6ee4000+14c000]
**

On Sat, 09 Mar 2019 14:18:45 +0000, Ken Schneider wrote:

> I’m seeing this also. I only have non-oss - oss - update and packman
> enabled.

Another “me 2” - segfaults at random points in reasonably lagre downloads
and then it will successfully restart. confirm what had been successful,
and complete the job w/o further problem. Running multiple machines via
ssh at the same time I’ve even seen one machine abend while everyone else
pressed on. Asked for an opinion on the cause, I would lean towards a
race or improper response to a data sream error. Glad I’m not chasing
this one- ‘random’ events are a nightmare!

At the moment I would rate this as a nuisance not a pending catastrophy…