Occasional System Crashes on Bionic64: Solved

[vtpup]

I made the switch from Tahrpup32 everyday and occasional Bionic64, to Bionic every day a few months back. Unfortunately I seem to be getting occasional X system crashes where BP64 drops to console. I can resume via typing in "xwin", though with all current work lost.

This is the same computer I've used for many years, and I never had spontaneous system crashes like this before in any other version of Puppy. I've gotten used to Puppy being crashless over the last decade! Now, it reminds me of the old Win98 blue screen days....

I don't know of a specific time that it happens (as in the recent thread about Palemoon and Youtube). I do use Seamonkey, and do view Youtube, but haven't (yet) noticed that they are necessarily in play when it happens. I'll try to notice in future.

But what I can report here now is the var/log/messages when it just happened minutes ago:

Code: Select all

Jun 28 17:12:38 puppypc20714 kern.info kernel: Qt bearer threa[7229]: segfault at 30 ip 00007f822572dd71 sp 00007f820b8ef720 error 4 in libQt5Core.so.5.9.5[7f82254a7000+53b000]
Jun 28 17:12:38 puppypc20714 kern.info kernel: Code: 0f 8c 8b 01 00 00 0f b6 05 2c 12 4c 00 84 c0 0f 84 0c 01 00 00 4c 8d 35 3d 12 4c 00 4d 8d 4e 30 66 0f ef c0 4c 89 f6 4d 89 cd <45> 8b 65 00 44 89 e5 81 e5 ff ff ff 00 83 fd 3f 0f 8e 59 01 00 00

[bigpup]

First, have you updated by using Quickpet -> Info ->Bionicpup updates?
Reboot and updated the save.
So now these new changes are being used.

This provides some bug fixes.

[williams2]

You could check whether the libQt5Core.so.5.9.5 file has been altered, like this:

Code: Select all

# md5sum /usr/lib/libQt5Core.so*
d13ce57db0ec71ecb1906f49381af0cf  /usr/lib/libQt5Core.so.5
d13ce57db0ec71ecb1906f49381af0cf  /usr/lib/libQt5Core.so.5.9
d13ce57db0ec71ecb1906f49381af0cf  /usr/lib/libQt5Core.so.5.9.5
# 
# md5sum /initrd/pup_ro2/usr/lib/libQt5Core.so*
d13ce57db0ec71ecb1906f49381af0cf  /initrd/pup_ro2/usr/lib/libQt5Core.so.5
d13ce57db0ec71ecb1906f49381af0cf  /initrd/pup_ro2/usr/lib/libQt5Core.so.5.9
d13ce57db0ec71ecb1906f49381af0cf  /initrd/pup_ro2/usr/lib/libQt5Core.so.5.9.5
# 

If the files have the same md5sum, then the files would not seem to have been altered.

If the libQt5Core.so QT5 library files are unaltered, then something that interacts with the QT5 library files may be incompatible, maybe a QT5 app, or even another library file.

What do you get if you paste this in a terminal:

Code: Select all

# echo $LD_LIBRARY_PATH 
/lib64:/usr/lib64:/usr/X11R7/lib:/root/my-applications/lib:/usr/local/lib
# 

I seem to have that file, but not in my $LD_LIBRARY_PATH
maybe there is a symlink to /usr/lib/ some where in $LD_LIBRARY_PATH

Trouble is, an application can modify $LD_LIBRARY_PATH to point anywhere it wants, for example, $LD_LIBRARY_PATH could point to a dir in it's own dir (for example, in a Rox Appliction Directory.)

Did you install something that uses QT5?

[Phoenix]

I made the switch from Tahrpup32 everyday and occasional Bionic64, to Bionic every day a few months back. Unfortunately I seem to be getting occasional X system crashes where BP64 drops to console. I can resume via typing in "xwin", though with all current work lost.

This is the same computer I've used for many years, and I never had spontaneous system crashes like this before in any other version of Puppy. I've gotten used to Puppy being crashless over the last decade! Now, it reminds me of the old Win98 blue screen days....

I don't know of a specific time that it happens (as in the recent thread about Palemoon and Youtube). I do use Seamonkey, and do view Youtube, but haven't (yet) noticed that they are necessarily in play when it happens. I'll try to notice in future.

But what I can report here now is the var/log/messages when it just happened minutes ago:

Code: Select all

Jun 28 17:12:38 puppypc20714 kern.info kernel: Qt bearer threa[7229]: segfault at 30 ip 00007f822572dd71 sp 00007f820b8ef720 error 4 in libQt5Core.so.5.9.5[7f82254a7000+53b000]
Jun 28 17:12:38 puppypc20714 kern.info kernel: Code: 0f 8c 8b 01 00 00 0f b6 05 2c 12 4c 00 84 c0 0f 84 0c 01 00 00 4c 8d 35 3d 12 4c 00 4d 8d 4e 30 66 0f ef c0 4c 89 f6 4d 89 cd <45> 8b 65 00 44 89 e5 81 e5 ff ff ff 00 83 fd 3f 0f 8e 59 01 00 00

It may or may not help if you run GDB and invoke it as such gdb xwin and issue continue (You may need to do this several times if it appears to stop because GDB reached some point where it paused again)

NOTE: There are many ways you can trigger a segmentation fault and that includes bad math with pointers, giving invalid values to functions, and many more including division by 0.

[bigpup]

If getting that libQt5Core.so.5.9.5 error to go away does not fix it.

At any time anything in the computers hardware can start to go bad and cause anything to happen.

First thing to consider:
Did you install or remove any kind of software just before this started happening?

You already started trying to see if it happens when you are using a specific program.

Could try booting Bionicpup64 without loading the save.
This will tell you if the save could have something in it causing this.

If none of this stuff applies.

You would be surprised what kind of strange problems dirt and dust inside a computer can cause.
Open up the computer and see how clean it is inside.

Not so much in laptops, but very much can happen in desktops where connections can get corroded, dirty, loose, bent contacts, etc....
I recently fixed my desktop computer doing strange things.
disconnected all connections, cleaned them, checked for bent contacts, cleaned all the dust out, and connected everything back up.
That fixed it.
Working 100% now.

[vtpup]

Sorry it's taken time to reply:

Bigpup, thanks, yes system has been updated to cuurent via QuickPet

Williams2, looks correct:

Code: Select all

root# md5sum /usr/lib/libQt5Core.so*
d13ce57db0ec71ecb1906f49381af0cf  /usr/lib/libQt5Core.so
d13ce57db0ec71ecb1906f49381af0cf  /usr/lib/libQt5Core.so.5
d13ce57db0ec71ecb1906f49381af0cf  /usr/lib/libQt5Core.so.5.9
d13ce57db0ec71ecb1906f49381af0cf  /usr/lib/libQt5Core.so.5.9.5

root# md5sum /initrd/pup_ro2/usr/lib/libQt5Core.so*
d13ce57db0ec71ecb1906f49381af0cf  /initrd/pup_ro2/usr/lib/libQt5Core.so.5
d13ce57db0ec71ecb1906f49381af0cf  /initrd/pup_ro2/usr/lib/libQt5Core.so.5.9
d13ce57db0ec71ecb1906f49381af0cf  /initrd/pup_ro2/usr/lib/libQt5Core.so.5.9.5

root# echo $LD_LIBRARY_PATH 
/lib64:/usr/lib64:/usr/X11R7/lib:/root/my-applications/lib:/usr/local/lib

Other questions:
No new software added in awhile.
Re. electronic and mechanical problems: the laptop performs fine when I dual boot into Tahrpup32 and (apologies) Win7. I have not ever had a single OS crash in anything other than the current BP64. Both those other OS's are present and work without crashing, which says to me it's not likely machine related. The BP64 crash seems to happen once every few days.

I'll try to be more observant about what is running when it does. I do suspect recent Youtube scripts may have something to do with it, but can't say that for sure. YT definitely stresses the system much more (judging from fan speedup and response slowdown) in the last few months or so. I think YT has a new script (I generally block everything not absolutely necessary to running a video w/Noscript) The jnn-pa.googleapis.com script seems new.

I'll try to answer any other questions missed.

[vtpup]

Phoenix, thank you. gdb xwin isn't recognized.

[vtpup]

Just remembered I was running a yt-dlp video download in console at the time. But in the background while doing something else.

[bigpup]

Looking at the specs for the Intel Celeron B815 dual-core processor, that is suppose to be in your laptop.
It does have ability to do two thing at one time, but it is very early ability specs.
None of the modern features newer processors have.
Very basic features for duel processing.
Very basic specs for memory control.

Same applies to the graphics ability.

So I guess, try only having one process, going on at a time, and see what now happens.

[williams2]

Your libQt5Core.so.5.9.5 shared object library file seems to be the correct file that came with the operating system. If it had been modifed, it would have been suspicious.

Trouble is, if you are running a browser like Firefox, it may be using it's own libQt5Core.so file, which might not be compatible with files in Puppy. AFAIk, it was in libQt5Core.so (Puppy's or Firefox's) that an instruction caused a segfault (reading or writing to ram that it was not allowed to access. That could be an incompatibility.

Even a modification of 1 bit could cause running software to crash, if it's the right bit.

For example, if a bit was corrupted somehow, some where in the operating system, a text file might have the text Guppy Linux instead of Puppy Linux, which would probably be harmless.

Or the bit might make the operating system unstable.

If other OSes are stable, it could be that there is broken hardware, but the broken hardware (like a bad bit in ram, might not important at all. Or the bad bit in ram might cause your system to be unstable.

Bad ram or other bad hardware could cause instability. Or it could be software.

Too little ram can cause it to crash. Since I've been running earlyoom (in Aditional Software, system), I've had it shut down Firefox and even Links, but the system has not slowed down or crashed. And the earlyoom logfile tells me why it did what it did.

There are various debug tools on the internet and in Puppy. I haven't used them much.

I'm running BionicPup64 now, it seems to be stable and reliable.

[mikewalsh]

The one major problem I've noticed with Bionicpup64 is a distinct reluctance to actually "see" its own Qt5 libs'n'stuff. Unless, of course, this is simply MY particular install. In every other respect - as with all other Puppies in the 'kennels' - BP64 is as reliable and rock-solid as the rest of 'em.

The only other issue I've had with BP64 is problems with getting Ethernet to connect properly.....but that's a moot point, as ozsouth compiled me a driver for the combo wireless/Bluetooth chip this HP desktop rig is 'blessed' with. Which works fine, so I basically side-stepped the issue! And that was after trying all of Rick Erwin's networking fixes.

In all day-to-day respects, it runs great. I don't think I've ever had an 'unprovoked' system crash with Puppy.....unless I've done summat really, REALLY stupid (in which case I kind of expect it..!) But it's nothing an external 'fix' from another Puppy - or a restore-from-backup (regularly, religiously performed!) - can't sort out.

Mike.

[vtpup]

Looking at the specs for the Intel Celeron B815 dual-core processor, that is suppose to be in your laptop.
It does have ability to do two thing at one time, but it is very early ability specs.
None of the modern features newer processors have.
Very basic features for duel processing.
Very basic specs for memory control.

Same applies to the graphics ability.

So I guess, try only having one process, going on at a time, and see what now happens.

No BP, it has an i5-2450M w/ 8 gigs of RAM and should be easily able to (and has in the last 8 months) run BP64. I've done major video editing in BP64 w/Kdenlive and other necessary adjuncts at the time like Gimp with no problems.

This is something new. And I'm definitely suspecting YouTube is at least a catalyst. I don't see remotely as high processor use with anything else, including video playback of streaming services, video editing, etc. All are easily accommodated. But even viewing YT comments starts winding up the fan and amping up proc threads, and slowing response.

As for running one process at a time, that would be a new limitation for any version I've used for puppy dating back to early Pup4 days.

BTW, I'm not attacking BP64 at all here, so people saying, gee it runs fine for me, are mistaking my reason for posting. I'm not dissing BP64, I'm simply trying to find out why this is happening in my particular instance, so I can continue using it. It's a fine OS.

I do not believe, though cannot obviously rule out, a hardware problem. But after 44 years of personal computing (I built my first PC from scratch) you get a feeling for these things. My feeling is that it isn't the drive or the RAM, it's what's being put there. Be glad to be proven wrong, because I can replace either easily. Finding why software is acting up is a heck of a lot harder.

I would normally not have even posted about this and troubleshot on my own, but I saw the other thread about BP64 crashes related to YouTube, and thought, hmmm, maybe mine are related -- maybe mention it on the forum.

[vtpup]

For further info:

The browser I run is Seaonkey. I'm one of those vanilla Puppy users with jwm rox seamonkey as the preferred trio. I even use the old icons. I like a stable system, vs a personalized one and assume most defaults are the best tested and proven ones.

[vtpup]

Williams2, Mike, I'm doing a pfind search now for "QT5Core" just to see if there are alternate versions onboard elsewhere....

[bigpup]

What I posted was based on what I thought you had for processor hardware.
This is the computer info you have in your signature.
Looking up the specs for this Acer Aspire 5349-2635 laptop.
It says it has the Celeron B815 dual-core processor.
So I guess this model could have any processor.

Now you know why supplying specific details and info are important.
I wish everyone could post an issue and provide this info:
https://forum.puppylinux.com/viewtopic.php?t=218

Do not know what version of Seamonkey you are using.
However, seems to be issues with the latest version.
Others have posted problems using it.

[vtpup]

I've found additional libqt5core versions onboard as:

/opt/Zoom/libQt5Core.so.5.9.6

and

/usr/lib/i386-linux-gnu/libQt5Core.so.5.9.4

I could get rid of Zoom (don't use it on this computer) but do need 32 bit compat.

[vtpup]

I downloaded memtester, then dropped to prompt, and ran it all this afternoon (hot day). Zero errors.
I rebooted to pfix=ram and then ran Gparted check on the Puppy partition (e2fsck). Zero bad blocks.

System was stable during the ram test, which is a pretty decent proc stress test, besides exercising RAM.

Seamonkey version is 2.49.4

[bigpup]

The latest Seamonkey is version 2.53.12
https://www.seamonkey-project.org/releases/

I was looking in the Bionicpup64 8.0 iso

There are a lot of symbolic links dealing with libQT5 different files.

They seem to be symbolic links to QT5 version 5.9.5 files.

Could look inside the save and see what QT5 stuff is added maybe by some program you have installed.
Look in /usr/lib in the save.

[vtpup]

Yup, thanks Bigpup, that's what I did with:

I'm doing a pfind search now for "QT5Core" just to see if there are alternate versions onboard elsewhere....

and

I've found additional libqt5core versions onboard as:
/opt/Zoom/libQt5Core.so.5.9.6
and
/usr/lib/i386-linux-gnu/libQt5Core.so.5.9.4
I could get rid of Zoom (don't use it on this computer) but do need 32 bit compat.

Those were the only two alternate versions of libQT5Core.so.xxx that I found.

I have removed Zoom since then, but not the 32 bit compatibility sfs.

I haven't yet had a crash and that may take awhile, but I will try to note down what was being used at the time...... if it happens again.

[mikewalsh]

Qt - regardless of the generation; Qt3, Qt4, Qt5 - is incredibly picky & fussy about having multiple different versions of itself on any given system.

You're okay having two versions if they're different generations; both Qt4 AND Qt5, say. This is quite normal. However, install two different versions from the same generation - say, 4.8.5 and 4.8.7....and all hell breaks loose. From that point on, nothing that needs Qt4 will condescend to run, UNLESS it's set-up to be self-contained and points itself specifically at its own included libs (and nowhere else).

Qt5 apps - to a much greater extent than Qt4 apps - are also very, VERY 'picky' about having the exact version they were built against. In theory, Qt is backwards-compatible.....but in practice, the Qt devs make so many changes & alterations from one release to the next, it would be a miracle if backward-compatibility EVER worked. At all.

Mike.

[vtpup]

Hi Mike, thanks.

That would mean that anyone who uses standard BP64 and loads the official 32 bit compatibility SFS will have exactly the same set of two versions of QT5 aboard. So what is your suggestion about how to handle that?

[mikewalsh]

@vtpup :-

Heh. I don't know as I really have any suggestions, TBH, 'cos I simply don't understand enough about the inner workings of Puppy to be able to offer any kind of "tidy" solution. MY 'solutions' would have many of the purists up in arms, I think.

I use all sorts of ugly 'hacks' & clunky workarounds that satisfy my needs, but I wouldn't wish some of them on my worst enemy..! But yes, you're right; anybody running vanilla BP64 and using the DevX package as it comes SHOULD have exactly the same stuff on the system.

Bionicpup64 had all sorts of "issues" that PhilB - bless him! - DID manage to largely sort out eventually.....but much of the trouble stemmed from the parent distro, Ubuntu 18.04. Canonical tried out a whole bunch of relatively untested ideas all at once, and for months afterwards - as far on as early the following year, in fact - Linux forums were full of complaints about 'such-and-such' not behaving itself, or 'so-and-so' acting in a totally different manner to what folks had got used to. It had a much longer spell of teething trouble than many of the previous LTS releases ever had; Xenial Xerus, Trusty Tahr, Precise Pangolin, Lucid Lynx, etc, were mostly stable and 'sorted' by the 2nd point release in the autumn of their launch year.

Even geeks don't like that much change all at once!

Sorry I can't offer anything concrete to show some light at the end of the tunnel....

Mike.

[vtpup]

Well, Mike, I would think that if other users of BP64 and the 32 Bit Compatibility sfs (not devx, btw) were having occasional crashes as a result of their slightly different QT5 versions, we'd have heard about it. I mean that must be a very common setup. In fact I'd guess that every BP64 user has the 32 bit compat sfs loaded.

IF, and that's a big IF, those two Qt5Core versions really were a problem for each other, it seems that to solve it, the 32 bit compatibility sfs version ought to be updated to match the standard BP64 version of Qt5Core. Yes? I mean since they are supposed to work as a team?

Or simply link to the usr/lib/ 5.9.5 rather than install a second iteration?

To clarify, stock BP64 is using:

/usr/lib/libQt5Core.so.5.9.5

and 32 bit compatibility sfs is (I believe) installing:

/usr/lib/i386-linux-gnu/libQt5Core.so.5.9.4

[mikewalsh]

@vtpup :-

TBH, there's no reason to. But you're simply comparing version numbers.....and overlooking the "i386-linux-gnu" component of the $PATH.

The former is in /usr/lib.....and in the 64-bit Pups, /usr/lib64 is a link to /usr/lib. The system is 64-bit, and that's one of the standard 'paths'.

The latter is clearly in the /i386-linux-gnu subdirectory, so by rights the system shouldn't even be looking there for its native items.....because it knows it's not going to find them there. Somewhere in the system, there's a file telling the 64-bit OS that the only things it will find in that sub-directory are 32-bit multiarch stuff, and that it WILL NOT find 'native' items in there.

Such is the idea behind the x86_64-linux-gnu & i386-linux-gnu directories in the Debian/Ubuntu-based OSs. This is how they keep 32- and 64-bit stuff separate, despite it being somewhat complex. Slackware, and many other distros, take the more practical approach of using both /lib32 AND /lib64 throughout the system.....no possible chance of confusion, and there's far less complexity into the bargain. Win-win!

--------------------------------------------

I've often thought the Ubuntu system is complexity purely for the sake of complexity. Shuttleworth showing-off again, simply trying to be clever.....and making a right pig's ear of it, as usual. I've also thought there must be something not quite right with the way that file I referred-to above has been written.....but don't ask me where to find it. Others probably know what I'm talking about; it's the file that defines standard $PATHs to the system, and tells it where it should look for certain items.

(*shrug*)

Mike.

[vtpup]

So the answer is they do not interfere with each other. And nothing needs to be done.

[bigpup]

I made the switch from Tahrpup32 everyday and occasional Bionic64, to Bionic every day a few months back.

I have to ask this.
Did you try to use the Tahrpup32 save in Bionicpup64?

You started using Bionicpup64, with it's own save, made from the very first shutdown of Bionicpup64?

All the stuff in the Bionicpup64 32bit compatibility sfs IS 32bit software.

/usr/lib/i386-linux-gnu/ is all 32bit software provided by the loaded 32bit compatibility SFS.

32bit software is not going to use any of the 64bit stuff that comes in Bionicpup64.
It is going to look for and use the 32bit software.

Usually, lib issues are caused by some software you install, that replaces stuff or moves it to wrong locations.
Puppies file system is not 100% exactly Linux, standard layout.
Some program packages, install stuff, in places that are not the normal place, in Puppies file system.

In a file manger.
If you actually access the Bionicpup64 save file/folder, by left clicking on it to show the contents.
You can look in the filesystem, in the save, and see exactly what got added to alter the Bionicpup64 file system, when the save is loaded.
This is the only way to see for sure, what is provided by stuff stored in the save.

[vtpup]

Yes Bigpup, I started with a new savefile in BP64.

[vtpup]

I have not had a crash since I first opened this topic. Basically I'm waiting before drawing any more conclusions, because I want to know what was running when (and if) it happens again.

The changes I've made since opening this topic are:

Removal of Zoom sfs (in case its Qt5Core version was causing problems)
Upgrading of Seamonkey to version 2.53.12 (current)

If Zoom's Qt5Core version was the problem, I may never see another crash, so this might be a long wait......

[bigpup]

I guess you know that Fossapup64 9.5 is the updated version to Bionicpup64 8.0.

It is basically Bionicpup64 8.0, but with much improved versions of everything.
A lot of improvements and bug fixes, provided by building using a much newer Woof -CE build system.
A lot of updated and bug fixed, newer versions, of Puppy core programs.

Fossapup64 9.5 does give better support for very new computers, but it also, still supports a lot of older computers.
As long as computer has a 64bit processor, close to 1GB or RAM, it should be fully supported.

[vtpup]

No newer issues so far.

I've also set up a new frugal w/ fossapup for test, Bigpup, but it usually takes a LOT of work to get everything I need the way I use it whenever switching to a new Puppy distro. I JUST made the switch to Bionic from Tahr some months ago, so doing that again won't happen soon unless there's a real need to give up Bionic. I don't like to constantly upgrade -- rather solve problems within a stable version. I use a lot of essential (to me) old software particularly CAD and CNC driver stuff, that more and more gets harder to bring along in upgrades. Still, if Fossapup works out better for some substantial reason, and I can still run my essentials, I may eventually move there.