Is there some kind of trace function I can use with Scriv?

So after you kindly and gently pointed out the problem I was having with aspell (thanks, I should recover from embarrassment eventually) I noticed that when I launch scrivener from a terminal window (by typing “scrivener”), when the program closes I get the following message:

Segmentation fault (core dumped)

Is there any flag I can use to try to capture more information to figure out why there’s a segfault on exit? That’s not a part of linux I’ve ever had to deal with overmuch.

strace. But you’ll get everything it dumps. Better to pipe it to a text file.

Here’s a good summary of it: mylinuxbook.com/linux-strace-com … leshooter/

Well that worked. Here are the last 24 lines:

shmctl(45711406, IPC_RMID, 0) = 0 <0.000031> poll([{fd=6, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=6, revents=POLLIN|POLLOUT}]) <0.000036> recvmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"\22\0\260\n\22\0`\7\22\0`\7\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 128 <0.000023> writev(6, [{"\213\7\2\0\36\0`\7\22\0\n\0\35\0`\7\210\1\0\0\210\1\0\0\10\2\0\0\20\0\0\0"..., 208}, {NULL, 0}, {"", 0}], 3) = 208 <0.000022> recvmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"\34\0\263\n\35\0`\7\210\1\0\0\202`\333\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 64 <0.000021> recvmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"\34\0\264\n\35\0`\7-\1\0\0\202`\333\6\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 320 <0.000042> recvmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"\34\0\274\n\22\0`\7\210\1\0\0\202`\333\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 64 <0.000035> recvmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"\34\0\275\n\22\0`\7m\1\0\0\202`\333\6\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 864 <0.000060> recvmsg(6, 0x7fff0c6b0df0, 0) = -1 EAGAIN (Resource temporarily unavailable) <0.000019> poll([{fd=3, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, events=POLLIN}], 3, 0) = 1 ([{fd=3, revents=POLLIN}]) <0.000034> write(3, "\1\0\0\0\0\0\0\0", 8) = 8 <0.000033> recvmsg(6, 0x7fff0c6b0df0, 0) = -1 EAGAIN (Resource temporarily unavailable) <0.000031> futex(0x32942bc, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x3294290, 4) = 1 <0.000041> futex(0x3294290, FUTEX_WAKE_PRIVATE, 1) = 1 <0.000034> futex(0x3226adc, FUTEX_WAIT_PRIVATE, 1, NULL) = 0 <0.000424> futex(0x3226ab0, FUTEX_WAKE_PRIVATE, 1) = 0 <0.000032> write(5, "@", 1) = 1 <0.000024> close(5) = 0 <0.000020> close(4) = 0 <0.000023> rt_sigaction(SIGCHLD, NULL, {0x7fd7e7ac3e20, [], SA_RESTORER|SA_NOCLDSTOP, 0x7fd7e7748340}, 8) = 0 <0.000013> rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x7fd7e7748340}, NULL, 8) = 0 <0.000014> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x7fd7eaa922d0} --- +++ killed by SIGSEGV (core dumped) +++

I don’t suppose this means anything to anyone?

Hrm, not seeing a cause, but I don’t do a ton of debugging that isn’t in a LISP terminal or uses csound output. Did it actually dump a core? Those can be useful, albeit huge. ulimit -c unlimited to make it actually save the core dump. (Warning, those can be very big.)

Did you have the file-import bug that some on 64 bit platforms had? (Was related to issues with gstreamer) I’d get Scrivener crashing at close on my ill-fated foray into Arch Linux. Since switching back to Slackware, I haven’t had it. Nearly as I could tell, it had to do with gstreamer, how it was compiled for Arch Linux, and the fact that Slackware didn’t have that issue.

Well I do have gstreamer installed, but I’m using VLC as my back-end.

If you are still seeing segmentation faults can I suggest the tip I found here …

bugs.launchpad.net/bzr-gtk/+bug/923824

i.e. temporarily patch /usr/share/pyshared/gobject/constants.py

Note that while the patch is in use other Python 2.7 apps may not run.
So after troubleshooting Scrivener fault you should reset constants.py to its default content.

i.e.

set temporary patch in constants.py
sudo gedit /usr/share/pyshared/gobject/constants.py

import sys
import gobject._gobject
raise ImportError(‘no static please’)

_gobject = sys.modules[‘gobject._gobject’]

save /usr/share/pyshared/gobject/constants.py

run Scrivener
observe output in terminal pointing to source of segmentation fault

reset constants.py to default content.

I now use a python script to quickly set/reset constants.py when troubleshooting python segmentation faults in different apps I’m testing/developing. But I’ve not yet hit a segmentation fault error in Scrivener.

I don’t have a constants.py in /usr/share/pyshared/gobject - I wonder if the problem is I’m missing some python resources Scrivener needs to run?

… found it in /usr/lib/python2.7/dist-packages/gobject

and I can confirm that with the patch in, Scrivener closes correctly.

Is there any way to do this with a flag? It seems like the easiest way to handle this would be to have Scrivener use a custom constants.py file when loading, so something like

scrivener -[flag that points to alternate constants.py with the no static please entry when loading]

which would allow all the other python apps in the world to use the default settings without having to swap out files all the time.

I’m not sure why terminal doesn’t point to the source of the segmentation fault when Scrivener is closed … possibly terminal is also closed when Scrivener is closed.

Here is the rough python code I use to set and reset constants.py … depending on whether the switch variable is “set” or “reset”. I guess that the switch variable could be passed in as an argument but for my purpose when testing other apps I just use two files … set_constants.py and reset_constants.py.

However I think that the source of the segmentation error should be tracked down rather than making this switch a permanent feature.

In fact my input_filepath = “/usr/lib/python2.7/dist-packages/gobject/constants.py”

set_constants.py

import os
import sys

def segmentation_error(switch):

    input_filepath = "/usr/lib/python2.7/dist-packages/gobject/constants.py"   
    i = open(input_filepath,"r") # open constants.py file with read only permissions   
    data = open(input_filepath).read() # read file contents
    i.close() # now close target file constants.py
    
    # data now equals file content .. file remains open
    
    if switch == "set":            
        separator = "import gobject._gobject"
        insertion = "\nraise ImportError('no static please')"

        # if file already edited purge to avoid duplication        
        data = data.replace("\nraise ImportError('no static please')", "")          
        
        # split string
        a, b = data.split("import gobject._gobject")          
        final = a+separator+insertion+b # included string: "raise ImportError('text')"  
        print "constants.py set"
  
    elif switch == "reset":       
        # purge edits of file      
        data = data.replace("\nraise ImportError('no static please')", "")          
        final = data
        print "constants.py reset"
        
    print "final: ", final 
    i = open(input_filepath,"w") # open file with write only permissions                
    i.write(final) # update file .. constants.py       
    i.close() # close target file
      
# ======================================
 
switch = "set"
segmentation_error(switch)
 
print "/usr/share/pyshared/gobject/constants.py is now set to ignore segmentation error"
 

1.7.2.3 might have fixed this problem, whatever it was. Didn’t get a segfault after upgrading. Fingers crossed!