I guess this could happen if a crash happens during program shutdown (right when the config file is being rewritten). Was it the case of your crash?

Also a solution could be to make copies of config files before writing them. This way, if a file is corrupted and unreadable for any reason on the next startup, we would try and load the backup instead.
This should not be too hard to implement. Of course it would not handle a case where a config file appears to be sane for some reason, but is not, like an incompletely saved file (unless we add some special text at the end of all config files, and if we don't find it, we assume the config file was not properly saved).

(In reply to Jehan from comment #1)
> I guess this could happen if a crash happens during program shutdown (right
> when the config file is being rewritten). Was it the case of your crash?

reasonable, but rather not, had never problems quitting Gimp. The crashes i get in v. 2.8.14 are clipboard op related issues and when painting very small, fast brush strokes. So, its a crash with Gimp running.

This is strange. I would not think we open the config files for writing except during GIMP shutdown. This is to be checked.

Do you have other bug reports related to the crash you are telling of? (2 crash reports at least: clipboard and painting related) If you don't, I would propose you to report these, in particular with reproduction steps.

(In reply to Jehan from comment #3)
> Do you have other bug reports related to the crash you are telling of? (2
> crash reports at least: clipboard and painting related) If you don't, I
> would propose you to report these, in particular with reproduction steps.

thanks for helping
there is already an open clipboard related bug, so i send my report to:
https://bugzilla.gnome.org/show_bug.cgi?id=743717#c6

i will submit the second bug report in this thread as soon as i get another crash with painting.

What makes this very curious is that we haven't received previous reports about such behavior, at least to my knowledge. Is there some OSX-specific behavior?

(In reply to Michael Schumacher from comment #5)
> What makes this very curious is that we haven't received previous reports
> about such behavior, at least to my knowledge. Is there some OSX-specific
> behavior?

I used gimp first on a ibook of apple, and now on a iMac of apple and also a Mac Pro of Apple. Maybe there arent so much pro painters using Gimp on a daily basis working on a Mac and submitting bug reports? I could work with photoshop, but since i touched the  Gimp, i loved it.

Created attachment 308216 [details]
crash during painting

as promised the 2nd part of the crash report. 
Couldnt simulate the bug, so i had to wait for one meanwhile working. 

Jehan, i hope the console output helps somehow to understand the problem, in any case dont hesitate to ask for further info. Thanks to all the Gimp developers.

Did this crash affect any of the settings this bug is about?

crash reports are rather cryptic, and developers have more tools to understand how problems arise, than an end user. A crash report is a crash report with some info to be interpreted.

Jo > I think Michael only wanted to point out that maybe you should have opened a new bug report specifically for the crash (and then link it here). Unless you are saying that each time this specific crash occurs, you lose all custom shortcuts, both issues could be considered separate.

Anyway I checked your backtrace. It looks like this specific crash occurs in files (tile.c, tile-manager.c…) which were removed from our development version in this commit.

-----------------------------------------------
commit 373a4e7469c0f24384f5aaef1a3af9dc39e035c3
Author: Michael Natterer <mitch@gimp.org>
Date:   Wed Jun 20 21:44:09 2012 +0200

    app: completely remove TileManager and friends (base/ and paint-funcs/)
    
    And along with it a lot of stuff like the drawable preview cache, the
    gegl tile manager backend, temporary gimp_gegl_buffer_foo() stuff, and
    the remaining bits of performance.
    
    The projection is in an evil semi-ported state which makes it work
    ok-ish for stuff like layer moving, but absolutely unbearable for
    painting, there is also an off-by-one rendering glitch at some zoom
    levels.
-----------------------------------------------

Now 2.8 is still our stable release, but I don't feel like spending too much time on fixing obsolete code, especially when this is apparently not too frequent a problem.
I don't know, maybe someone else would.

As for the main issue of this bug report though (losing config file information), I verified and confirmed that the only 3 times a write is made on the `menurc` file (where custom shortcuts are saved), this is during a proper program exit, or when you click "Save Keyboard Shortcuts _Now" and "_Reset Keyboard Shortcuts to Default Values" in the Preferences.
The only other access to the file is a read-only access during startup, with a proper close in the end (I even went as far as checking GTK+ code to make sure of this).

I really don't know how a deletion of the file could occur other than during a crash on exit (or just when you click the "Save/Reset" buttons in Preferences.
Could you check the "menurc" file in ~/Library/Application Support/2.8/ ?
Check its contents (are your shortcuts really not saved there?), maybe the file permission (or the directory permission), which could prevent proper load/save.

I don't see much what could be the problem.

I just wanted a simple "yes" or "no" for an answer.

(In reply to Michael Schumacher from comment #11)
> I just wanted a simple "yes" or "no" for an answer.

its no. Fortunately Gimp loses its custom preferences seldom, its rather impossible to simulate such a particular crash.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/706.