Crash reported in 64-bit pvm-0.1.17 #5
Comments
|
This is still a problem in July 2020.... dmesg shows crash: |
|
The p-v-m implements classes and stuff and I probably deleted a few more lines than I should have. Does 0.1.15 work ok? I was planning to rewrite the pvm using the same logic as ... I don't even recall the name of some scripts. Without the gobject stuff. Although now I understand gtk and glib a bit more and I guess I'm in the position to fix issues. |
|
What I'll do is rename the project and change the whole codebase, but not now. Meanwhile I can try to see what's wrong, but I need a link to a ISO file + a working devx. I must compile pvm with debug symbols and perform a |
|
Thanks @wdlkmpx - great to hear from you again..... hope you can squish this long standing bug ;-) |
I don't seem to have either a compiled 64-bit compatible package or the 0.1.15 sources to compile a new version so unable to confirm..... |
You can checkout any other sha hash the same way. That commit is the last one before the day that pvm was bumped to 0.1.16 |
|
Ok I performed a The segfault happens in The app is unusually big with duplicate code and convoluted glib - gobject stuff that requires reading a 600-page book first. I guess it could be like 10 times simpler.. I guess that's why I was just thinking of rewriting it. The PVM doesn't work with 'native' glib2 .deb packages, that is something really disturbing, I have some questions:
I say this because It might not be worth fixing the bug. |
|
As far as I know, the bug only affects 64-bit systems so the answer is: But I will check and report back. |
|
ScPup64 has the problem; ScPup32 does not..... |
|
slacko64-6.9.9.9 has the problem: |
|
BionicPup64 with pvm-0.1.15 - ok, no segfault BionicPup64 with pvm-0.1.17 - segfaults |
|
pup-volume-monitor-0.1.15.tar.gz I compiled, installed and tested pvm several times and found the same segfault. It was probably executing the same binary that was hidden behind the aufs layer, I didn't reboot. It probably has to do with the "updates" (GTask vs GSimplesyncResult), but in my tests everything failed. But why does it only happen in 64 bit builds? Learning GIO, GObject and so on will take a month at the very least. It took me half a year to understand things to be able to edit gftp and this presents a similar challenge. But I think it's easier to rewrite it without udev using basic glib stuff, and busybox as the library to get info about partitions. There are scripts and sample c files (hotplug2stdout.c) that provide some insight on how to things without udev. |
|
Thanks for 0.1.15 |
|
Hmmm it was not the correct revision, the old sources fail to pass the autoreconf stuff. I did test everything, assuming a different binary was being executed. This is what I'll do:
That will result in pvm 0.2.0 or 0.2.0b It may take a week or a month or maybe 2 months, patience is the key as I'm updating other projects as well. Currently the main problem is the weather, it's too cold, even my thoughts are freezing |
|
No worry - your efforts are appreciated - we've had the bug since 2018 at least so a few more months will soon pass ;-) |
|
No matter how many changes I undo, I always get the same crash at the same place Compiling and testing with
So it will take some time. |
|
Thank you for your efforts - it sounds like it must be a very obscure problem given that it is specific to 64-bit systems. I have reverted to 0.1.15 for 64-bit while still using 0.1.17 for 32-bit but I doubt that end-users will be able to detect any difference..... |
|
I edited the pvm because I was seeing a weird behavior sometimes, and it crashed once. I know there were some glib critical errors in xerrs.log. But other than that it was working fine. The pvm requires a deep understanding of the gobject system, it creates classes, signals, events, threads, hash tables, etc. The whole glib package. Probably a race condition happens or maybe something else, 'cause I added debug strings that don't seem to be printed for some reason. I compiled pvm in lucid pup and it doesn't show the drives, the fact that it doesn't support the debian patched glib makes it less appealing to me. But I'll be investigating how to fix this, it's the only volume monitor I use and maybe I'll find a way to fix the bug in the coming weeks or months. |
|
I see the app was created with an Integrated Development Environment, which makes it twice as hard to understand. Some gtk apps create GTK_TYPE_* derived classes, I mostly don't understand those apps. I guess the IDE created the classes and stuff and automatically generated headers or something, I only use geany. So I need to reorganize the code a bit to be able to understand it, and more importantly I have to read the GObject reference manual thoroughly. The thing is, this is 100% gnome DE code, it needs to be simplified a bit The only required part is the GIO module, the pvm could be a very simple app that is triggered by a udev rule and sends the info to the GIO module. When an app is called by udev it also receives info about the partition through environment variables, so there's no need to use libblkid. Overall I know how to reimplement everything in a different way, in a very simple way, I've already done that with pup_event / probedisk / probepart. But this is a technical challenge I hope to overcome one day. |
|
http://distro.ibiblio.org/puppylinux/pet_packages-fossa64/pup-volume-monitor-0.1.17-fossapup64.pet |
|
Clarification:
|
|
With a heavy heart I must admit that I still haven't got around to try
to fix the app.
But the lxpup current I downloaded months ago has some issues:
- no gmrun
- geany: ctrl+L doesn't work (update it to the latest version)
- other subtle issues with geany
- no gtk3 .. this is more serious than you think. right now I can't
downloading anything bigger than 50kb
7z doesn't work, you need to repackage p7zip
replace usr/bin/7z* with scripts
#!/bin/sh
exec /usr/libexec/7z "$@"
for some reason a symlink breaks p7zip (only) in slack-based os'es.
|
|
Hi @wdlkmpx
Thanks |
|
Hi @wdlkmpx p7zip is a .pet from common64 uploaded 20-Aug-2019: geany is also a .pet from Slacko64-14.2 - version 1.35 uploaded 25-Nov-2020 so pretty recent.... |
|
7z can't decompress anything, the reason: it can't find the .so file.
But I know it works with scripts instead of symlinks, and the issue
only happens in slackware based operating systems.
This p7zip fork looks promising
https://github.com/jinfeihan57/p7zip
I just noticed that ctrl+L works in geany, it shows something in the
toolbar, it's no longer an input box, but I did notice something. I
don't have the latest iso, and I can't download the current one, my
internet is pretty limited nowadays, and it's so limited even
downloading the gtk3 package seems a bit too much.
But that's not the reason, the current stuff is something that will
break after a few months, installing some packages will produce broken
stuff, that's why that offering should come a bit more complete, as
it's only for experimentation (just like everything that's not
stable). I noticed that gtk2 packages produce a lot of warnings now.
|
|
The common p7zip works in all distros. I know it works without a
recompile in slackware because I replaced the symlinks with scripts,
and that was the fix.
Producing generic stuff has its quirks and requires a lot of testing.
The only significant change to the petbuild was the change from
scripts to symlinks.
Someone should revert that change and many other changes I guess,
compiling for a specific distro-version is the only reliable way,
after all.
|
|
Some further tests revealed something that was obvious from the beginning, a NULL check leads to a wrong code path, and it doesn't make sense at all... how that is even possible. I'm going crazy, this should not be happening. Both I'm still using lxpup sc 20.06. Something is wrong, but I must go out somewhere to download a new iso, and it better have gtk3 (locales and docs are ignored), and probably python3 in the devx. I should test with an older kernel, but it's somewhere in the world wide web. I guess gcc is miscompiling stuff or something, this is crazy. |
|
Perhaps you'd be better off using FossaPup64 ?? |
|
Some further tests revealed that I'm crazy, `if (!drive)` evalutes to
false but `drive` is NULL (0x0), so this doesn't make sense. So it's
a NULL pointer that is identified as non-NULL.
g_hash_table_lookup returns NULL or a potentially valid pointer, but
something shady is going on.
|
|
It will be days or weeks or a couple of months perhaps before I
download a iso file and it will be a lxpupsc 64 bit, but it's
interesting how the app is mysteriously broken, it's something like
"I, robot", VIKI said something totally logical about humankind's
autodestructive nature, Sonny agreed and disagreed at the same time,
it doesn't make sense.
|
|
Honestly the app should not crash, there are safeguards against
crashes. If something goes wrong, it should misbehave, but not crash.
I've tested in a 32bit distro and the null tests pass correctly, the
weird thing happens only in lxpupsc64.
And it's baffling, perplexing, disturbing. Because it makes no sense
how it can happen. Artificial intelligence trying to drive me mad.
There is no doubt in my mind that this is the beginning of Skynet -
rise of the machines.
I fixed the issue with a very weird hack, it works for me with
lxpupsc64 20.06, but others should test.
How to test:
git clone -b master --depth 1 https://github.com/wdlkmpx/pup-volume-monitor
cd pup-volume-monitor
./autogen.sh
./configure --prefix=/usr --sysconfdir=/etc
make install
(reboot, test)
|
|
Excellent @wdlkmpx - many thanks - looking good.... Tested on: ScPup64-21.01, LxPupSc64-21.01; BionicPup64 and FossaPup64 - all seem OK. Should it remain as a 0.1.17 variant or be 0.1.18? |
|
Forum thread: |
|
0.2w pets (32 & 64-bit) available via forum. Many thanks @wdlkmpx |
|
For 64bit slackware I guess ./configure ... --libdir=/usr/lib64 makes sense.
Packages for testing will only work in distros older than the one it
was compiled in, but here's the caveat:
The package itself is generic: it will compile and probably work as
expected in ubuntu lucid (2010), the last time I tested it did work.
But some functions and stuff used are different if you compile it in
slackware current.
The way to go is to remove older stuff but add #defines and tricks to
make it compile with ancient distros, defining compat functions
(glib-compat.h).
|
|
I meant "a package for testing will only work in distros newer than
the one it was compiled in".
So basically the package must be compiled for a specific distro
version, that's why compiling is a big deal and a must for testers,
Now, the crash, why did it happen. I guess voodoo happens in GObject, who knows.
Now why does the pvm not work with the default ubuntu/debian glib?
Maybe it does now, but I have no way to test. The app is indeed quite
an achievement for someone that didn't belong to that obscure
organization called Gnome.
|
|
:-)) |
|
I really don't know if any of those upups include a different glib
package than the standard .deb package. The fact is, people recompiled
glib2 for upup precise, tahr, etc. I recompiled it for pstretch.
So in fact the pvm was/is broken for debian/ubuntu based operating
systems, unless other type of "derivatives" somehow made it work
without recompiling glib2.
Compiling a generic package and avoid some deprecated glib that might
behave strangely in later versions.. perhaps xenial should be the
base, otherwise deprecated functions and stuff are in use.
That doesn't negate the fact that some packages are fully up to date
and compile in really ancient distros... slightly different rules
apply to those ancient distros, but after applying a thousand fixes
for recent versions, those ancient distros still benefit from the
changes, as glib includes more warnings and stuff that should be fixed
in later versions.
|
|
Well as an example, UPupHH+D uses: :glib:|compat|Packages-ubuntu-hirsute-main|libglib2.0-0_2.66.4-1|libglib2.0-0|2.66.4-1||BuildingBlock|4500K|pool/main/g/glib2.0|libglib2.0-0_2.66.4-1_i386.deb|+libc6&ge2.32,+libffi8ubuntu1&ge3.4,+libmount1&ge2.35.2-7,+libpcre3,+libselinux1&ge3.1,+zlib1g&ge1.2.2|GLib library of C routines|ubuntu|hirsute|| |
See:
http://murga-linux.com/puppy/viewtopic.php?p=1008421#1008421
64-bit pvm-0.1.17 crashes on insertion of external drive with:
pool[7353]: segfault at 40 ip 00007f2127bb54f0 sp 00007f21263b6dd8 error 4 in libpupvm.so.0.0.0[7f2127ba9000+13000]
Code: 40 00 48 8b 05 11 6b 20 00 48 8b 00 48 85 c0 74 e4 ff d0 48 89 df 5b e9 de aa ff ff 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 <8b> 47 40 85 c0 74 09 48 8b 07 ff a0 a0 00 00 00 c3 0f 1f 44 00 00
The text was updated successfully, but these errors were encountered: