Seg fault / core dump on exit on 1.9.0.1-i386

df
df7aylor
Posts: 3
Joined: Thu Jan 07, 2016 9:51 pm
Platform: Linux

Thu Jan 07, 2016 10:11 pm Post

Just installed 1.9.0.1-i386 on a fresh Fedora 23 (x86_64) system.

Had to install a bunch of dependencies:

sudo dnf install cups-libs-1:2.1.2-1.fc23.i686
sudo dnf install libX11-1.6.3-2.fc23.i686
sudo dnf install libpng12-1.2.56-1.fc23.i686
sudo dnf install libXrender-0.9.9-2.fc23.i686
sudo dnf install gstreamer-plugins-base-0.10.36-13.fc23.i686

to get it to run, but it starts up OK and reads my old .scriv files, and I think is writing them OK. I'm worried though, because it seg faults and core dumps on exit every time. I think at least one other person has had a similar problem based on this commen from the release thread:

Re: Linux 1.9.01 Beta Released

Postby Fapi on Tue Nov 03, 2015 1:06 pm
Yes...1.9. thx...but there are some questions to the new beta at my side:

- where is the scrivener.sh in the 64bit tar.gz?
- why stops the new version with a dump?

So does anyone have any insight on the messy exit status? Am I doing something wrong here? I installed the i386 version rather than 64 since I'm running on a x86_64 system not an AMD64...

I will post the exit output if anyone cares to look at it... it's long. The first part looks like this:

> QString::arg: Argument missing: Updating..., NameOfProjectIWasWorkingOn
> *** Error in `Scrivener': double free or corruption (!prev):
> 0x0a2e7f00 *** ======= Backtrace: =========
> /lib/libc.so.6(+0x6b09b)[0xf429a09b]
> /lib/libc.so.6(+0x7400a)[0xf42a300a]
> /lib/libc.so.6(cfree+0x50)[0xf42a66e0]
> /lib/libstdc++.so.6(_ZdlPv+0x1c)[0xf44d6f2c]
> /usr/local/bin/scrivener-1.9.0.1-i386/bin/../lib/libQtCore.so.4(_ZN7QRegExpD2Ev+0x64)[0xf46b4774]
> /lib/libc.so.6(__cxa_finalize+0xbc)[0xf425fdbc]
> /usr/local/bin/scrivener-1.9.0.1-i386/bin/../lib/libScrProject.so.1(+0x4fac4)[0xf7293ac4]
> /usr/local/bin/scrivener-1.9.0.1-i386/bin/../lib/libScrProject.so.1(+0x1846ad)[0xf73c86ad]
> /lib/libc.so.6(+0x30a63)[0xf425fa63]

ph
philjaq
Posts: 29
Joined: Tue Dec 22, 2015 7:07 pm
Platform: Linux

Thu Jan 07, 2016 11:18 pm Post

df7aylor : first I would have thought with a 64 bit processor that you would have used the 64 bit scrivener package. 32 bit stuff will normally run on a 64 bit processor but will probably need other 32 bit supporting dependencies installed.

I'm using the 64bit deb package on UbuntuStudio1404LTS - just starting with scrivener so I'm not familiar with all its foibles. But I have noticed odd error boxes popping up some minutes after closing scrivener down but only sometimes. These boxes inform me that scriv had some problem but I never took much notice since it hasn't had any adverse effects that I've noticed so far.

I just restarted scrivener to check and noted that scriv was using pid 16630. I shut down. No apparent error box to say scriv had crashed and I rechecked the log. The following section had been added :

ERROR: apport (pid 16708) Fri Jan 8 00:02:15 2016: called for pid 16630, signal 6, core limit 0
ERROR: apport (pid 16708) Fri Jan 8 00:02:15 2016: executable: /usr/share/scrivener/bin/Scrivener (command line "/usr/share/scrivener/bin/Scrivener")
ERROR: apport (pid 16708) Fri Jan 8 00:02:15 2016: gdbus call error: Error: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files
ERROR: apport (pid 16708) Fri Jan 8 00:02:15 2016: debug: session gdbus call:
ERROR: apport (pid 16708) Fri Jan 8 00:02:15 2016: this executable already crashed 2 times, ignoring

I never saw any pid 16708 on the system monitor. And these shutdowns don't seem to have lasting effect so I'm ignoring them until I have reason to think otherwise.

Without the occasional error box, I certainly wouldn't have been aware that scrivener had 'crashed.'

Evidently there is something 'messy' about scrivener's shutdown on (some) linux boxes.

df
df7aylor
Posts: 3
Joined: Thu Jan 07, 2016 9:51 pm
Platform: Linux

Thu Jan 07, 2016 11:27 pm Post

philjaq, thanks for the reply.

I grabbed the i386 version because AMD64 and x86_64 didn't *used* to be the same... at least in Fedora... not sure that's the case anymore. I think I got all the 32 bit libraries installed, though. I am trying it again using the 64 bit .deb, and trying to make an rpm out of it using alien (which I gather is notoriously ill mannered). Failing that, may try the 64 bit tarball.

I'm seeing these errors when running from the command line, but it isn't clear that there's anything wrong with the way scrivener is running or handling files, just that it's exiting badly (which makes me worry a bit about losing work if the system locks/crashes/loses power or I forget to shut scrivener down nicely before turning things off).

<edit>

Just tried the amd64 tarball; runs, seems to work, same messy exit. I guess if it works otherwise I'll just run with it.

ka
kataja
Posts: 17
Joined: Sat Sep 28, 2013 5:19 pm
Platform: Linux

Sun Jan 10, 2016 8:14 am Post

I wonder if that is related to what is happening to me almost every time. I usually leave just by closing the window, the program seems to close cleanly (all from graphical interface) telling it's running backup etc.

But a moment later there appears (at the top of what I happen to be doing, usually browser) an error message telling that "Scrivener closed suddenly". (I cannot give exact words as I have system installed in Finnish and thus that error message is in Finnish, too).

Seems to be just a glitch as next time I open the program everything seems normal again (and I have not lost editing or anything).

32 bit version on Acer Aspire one 725 running Ubuntu linux 12.04.

pa
paweston
Posts: 1
Joined: Sun May 08, 2016 9:12 pm
Platform: Linux

Sun May 08, 2016 9:27 pm Post

On the CLI I get:
*** Error in `/usr/share/scrivener/bin/Scrivener': double free or corruption (!prev): 0x0000000002b58510 ***
Aborted (core dumped)

I am not a programmer ("I don't often program, but when I do..."), but if I remember correctly, a malloc returns a pointer to reference the memory allocation. If you free the memory (at the pointer) then you are no longer authorized to reference that memory. If you free it a second time it should result in a segmentation fault.

I don't know what sort of corruption could happen each and every time you close the app, but that is above my pay grade (which is zero in this case).

I don't think it causes any damage per se, but it is an annoyance.