abrt 1.0.9 detected a crash. architecture: x86_64 Attached file: backtrace cmdline: deja-dup-monitor comment: ran cli yum update using updates-testing component: deja-dup executable: /usr/bin/deja-dup-monitor global_uuid: 14330f5a0328bc9f53ef8522bf0ce96bd7861ae2 kernel: 2.6.33.2-57.fc13.x86_64 package: deja-dup-14.0.3-1.fc13 rating: 4 reason: Process /usr/bin/deja-dup-monitor was killed by signal 6 (SIGABRT) release: Fedora release 13 (Goddard)
Created attachment 410113 [details] File: backtrace
Thanks for the report, Clyde! This crash is due to a mistaken use of g_error (which aborts the program) instead of g_warning to report an error on the console. I've fixed that in trunk and it will be in the forthcoming 14.1 release. I'm a little confused why you hit that code path, because it means there was an error reading values from gconf. Is your gconf setup odd? Specifically, when trying to read one of these keys (I don't know which one caused the error): /apps/deja-dup/periodic /apps/deja-dup/periodic-period /apps/deja-dup/last-run
FYI, I have pushed 14.1 as an update for Fedora 13 https://admin.fedoraproject.org/updates/deja-dup-14.1-1.fc13 Before you update though, you might want to help debug the root cause of this problem. Check the gconf settings.
Back from visiting new twin gandkids!! I am not aware of any unusual settings in gconf, but then again, how do I know or even check? Not seeing the error now, and haven't made any changes other than massive update catchup. My home partition is shared with rawhide, F13, 12, 11, 10, and centos.
Congrats! :) Unfortunately, I don't really know how to investigate a gconf error either. I'm not sure under what situations you would not be able to read your own gconf settings. If you're not seeing the error now, I wouldn't worry about it. Might have been some goofy transient thing...
Without this being reproducible, I have to close it. Feel free to reopen if you this happens again.