~ % /Applications/darktable.app/Contents/MacOS/darktable
(process:52931): GLib-GObject-CRITICAL **: 22:27:01.490: g_object_set: assertion ‘G_IS_OBJECT (object)’ failed
and that’s it. The process hangs.
dt’s package contents are all read/write to me as they should be. If that’s not what you mean, I’d be grateful for a steer about what to look for and where.
In the macos system preferences, there is something for disk access. They keep changing where it is, so I’m not 100% sure.
I’m sorry, but I can’t find anything like that in system preferences for Monterey 12.13.1
I’ve restored dt from Time Machine backup (date just before OS update). dt now starts in about 20-30s. (But my mac has a spinning metal hard drive; and the image files are on a NAS.)
However, trying to start dt in terminal still produces the rather worrying one-liner
(process:nnnnn): GLib-GObject-CRITICAL **: [time] : g_object_set: assertion ‘G_IS_OBJECT (object)’ failed
What’s that about??? And why is it CRITICAL! (I’m not a programmer, and have know idea what GLib and GObject are.)
Thanks for the link. I should say that I’ve been running dt on mac for several years, and upgrading to new releases. So I’ve dealt with Mac’s ever-more-fierce security blocks on ‘unknown developers’ etc. And my current installation has been running fine since updating to dt 3.8.1; so forgive me fore not being convinced this is that sort of issue.
It’s more like this:
in reply to which, Martin says: “btw: the gtk messages are just a reminder that gtk and osx aren’t best friends …”
He’s not kidding, is he?!
Thanks for your kind support. I think I’ll try re-installing from scratch, and restoring .cache from my routine backups…
Sorry, not .cache! I meant .config/darktable, of course.
I never said this was the issue you’re having, but since I can’t she your machine and you can’t provide much information, we start troubleshooting from a very common issue and move on from there.
I can’t find any problem with permissions, or any Gatekeeper issues. I reninstalled dt 3.8.1, but the program would not start. So I tried starting with a fresh .config/darktable, and the program would then run.
I concluded that the issue might be a problem with my database or config files, so I rolled them back via Time Machine to a version that had been working OK. dt then opened properly.
I’ve been using dt during the day, including closing and restarting it. It sometimes fails to start properly, either failing to open at all, or only opening a rectangle at the top left of my Mac screen and then not drawing the full UI. Or it takes a very long time (2+ minutes) to start.
When it stalls, I have to do a forced quit. It sometimes then restarts OK; or it hangs again, and needs another forced quit to get it to start.
So I am managing to get dt to start in this clunky way. But I’m seriously wondering wether I’d be better off moving it on to an old laptop that I have running Debian Buster. I’ve been reluctant to do this as the screen is nowhere near as good as my 2017 iMac Retina 4K, 21.5-inch machine. But in view of the persistent problems I may give the Dell Inspiron 3521 running Buster a go tomorrow to see whether it’s usable.
Now you’re reporting a multitude of different things, instead of just one concise report. And these new reports seem.to conflict your previous statements.
While I understand and empathize that this is your experience, I hope you understand that I can’t see your computer nor do I use macOS often enough to be an expert. There is a method to troubleshooting that I try to follow in order to eliminate common issues first and work, sometimes slowly, towards resolution, but if you’re not on that journey with me, then it is difficult to help.
I entirely understand that, and appreciate your assistance. I will try to give you specific replies to your troubleshooting questions.
To wind back:
What would you suggest I do next?
Are you launching from the terminal with the -d all syntax? E.g. /path/to/darktable -d all as I’d expect more output if dt is choking on your database/config files.
If this runs, why are you rolling back?
I’m sorry, as you can see from my reply to your initial request for the out put, I did not use the -d all syntax.
I have just done so. dt started, and I did, indeed, get a lot of terminal output, starting with
/Applications/darktable.app/Contents/MacOS/darktable -d all
0.001620 application_directory: /Applications/darktable.app/Contents/MacOS
0.001919 darktable.datadir: /Applications/darktable.app/Contents/Resources/share/darktable
0.002141 darktable.plugindir: /Applications/darktable.app/Contents/Resources/lib/darktable
0.002347 darktable.localedir: /Applications/darktable.app/Contents/Resources/share/locale
0.002540 darktable.configdir: /Users/imac/.config/darktable
0.002746 darktable.cachedir: /Users/imac/.cache/darktable
0.002931 darktable.sharedir: /Applications/darktable.app/Contents/Resources/share
0.021326 darktable.tmpdir: /private/var/folders/rx/1209jgc90fl4m4x55zt3sgbc0000z8/T
[memory] at startup
[memory] max address space (vmpeak): unknown
[memory] cur address space (vmsize): 34320748 kB
[memory] max used memory (vmhwm ): unknown
[memory] cur used memory (vmrss ): 12996 kB
0.021366 new_xdg_data_dirs: (null)
(process:1874): GLib-GObject-CRITICAL **: 18:42:33.782: g_object_set: assertion ‘G_IS_OBJECT (object)’ failed
1.620133 [init sql] library: /Users/imac/.config/darktable/library.db, data: /Users/imac/.config/darktable/data.db
1.957083 [sql] /Users/parafin/src/darktable/src/common/tags.c:586, function dt_set_darktable_tags(): exec “DELETE FROM memory.darktable_tags”
1.957129 [sql] /Users/parafin/src/darktable/src/common/tags.c:594, function dt_set_darktable_tags(): prepare “INSERT INTO memory.darktable_tags (tagid) SELECT DISTINCT id FROM data.tags WHERE name LIKE ‘darktable|%%’”
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
1.957644 [sql] /Users/parafin/src/darktable/src/common/film.c:487, function dt_film_set_folder_status(): prepare “DELETE FROM memory.film_folder”…
and running on for many, many more lines till currently it’s showing this…
462.874799 [sql] /Users/parafin/src/darktable/src/common/tags.c:634, function dt_tag_get_attached(): prepare “SELECT DISTINCT I.tagid, T.name, T.flags, T.synonyms, COUNT(DISTINCT I.imgid) AS inb FROM main.tagged_images AS I JOIN data.tags AS T ON T.id = I.tagid WHERE I.imgid IN (SELECT imgid FROM main.selected_images) AND T.id NOT IN memory.darktable_tags GROUP BY I.tagid ORDER by T.name”
534.548028 [lighttable] expose took 0.0000 sec
534.657454 [lighttable] expose took 0.0000 sec
534.738988 [lighttable] expose took 0.0000 sec
535.544904 [lighttable] expose took 0.0000 sec
535.644077 [lighttable] expose took 0.0000 sec
535.725566 [lighttable] expose took 0.0000 sec
The terminal output is long. Would it be useful for me to redirect the output to a file, and dm that to you?
I assumed (perhaps naively?) that this was the only way to avoid the labour and time of having to add my 1.8 TB of image files to new databases from scratch. Am I mistaken about this?
This time when I ran the -d all option and dt started, there was nowhere near as much output. This is what I got:
[memory] at startup
[memory] max address space (vmpeak): unknown
[memory] cur address space (vmsize): 34320748 kB
[memory] max used memory (vmhwm ): unknown
[memory] cur used memory (vmrss ): 12936 kB
(process:2347): GLib-GObject-CRITICAL **: 19:16:46.075: g_object_set: assertion ‘G_IS_OBJECT (object)’ failed
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
(darktable:2347): GLib-GObject-WARNING **: 19:16:50.863: invalid cast from ‘GtkMenuBar’ to ‘GtkWindow’
(darktable:2347): Gtk-CRITICAL **: 19:16:50.863: gtk_window_add_accel_group: assertion ‘GTK_IS_WINDOW (window)’ failed
^^^^^ modulegroups
vvvvv
[memory] after successful startup
[memory] max address space (vmpeak): unknown
[memory] cur address space (vmsize): 34486044 kB
[memory] max used memory (vmhwm ): unknown
[memory] cur used memory (vmrss ): 110216 kB
wait time 0.420847s
try- wait time 0.360059s
wait time 0.159195s
try- wait time 0.144612s
wait time 0.142145s
wait time 0.152251s
try- wait time 0.151018s
I’m very sorry, I didn’t clock that there was much more in the output file than was appearing in Terminal. The pastebin copy is here:
https://pastebin.com/zkbZYxH5
I assume this log is where dt hangs and you kill it eventually?
Its taking a while because it builds all your openCL kernels, then starts optimizing your database, which make take a while depending on size, see the last line:
dt_database_optimize(): exec "PRAGMA optimize"