Some of gnome-chemistry-utils crash on startup

[watsodw]

Gchemcalc, gchemtable abort with message: "libc++abi.dylib: terminate called throwing an exception". 10.8.3, Xcode 4.6.3

[c.herbig@…]

Cc Me!

[c.herbig@…]

Yes, unfortunately this seems to be a "known issue" for running it on OS X, but no one seems to know why. The only progress we've made so far is ticket #39863, which only seems to fix an issue with gchempaint not closing from the close button on the menu bar. I've been trying to work with the project developers, but it's not something that I've been able to put enough time into yet. Of course, if you have lots and lots of spare time, then any help you could provide would be very, very much appreciated.

[c.herbig@…]

Also, if you have any feedback on which apps do work correctly, that could be helpful as well.

[neverpanic (Clemens Lang)]

The crash report seems to indicate it might be related to locale stuff:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fff8f8e6212 __pthread_kill + 10
1   libsystem_c.dylib             	0x00007fff8e149b54 pthread_kill + 90
2   libsystem_c.dylib             	0x00007fff8e18ddce abort + 143
3   libc++abi.dylib               	0x00007fff8e4e89eb abort_message + 257
4   libc++abi.dylib               	0x00007fff8e4e639a default_terminate() + 28
5   libobjc.A.dylib               	0x00007fff9275d887 _objc_terminate() + 111
6   libc++abi.dylib               	0x00007fff8e4e63c9 safe_handler_caller(void (*)()) + 8
7   libc++abi.dylib               	0x00007fff8e4e6424 std::terminate() + 16
8   libc++abi.dylib               	0x00007fff8e4e758b __cxa_throw + 111
9   libstdc++.6.dylib             	0x00007fff8e01e4b8 std::__throw_runtime_error(char const*) + 85
10  libstdc++.6.dylib             	0x00007fff8e059237 std::locale::facet::_S_create_c_locale(int*&, char const*, int*) + 47
11  libstdc++.6.dylib             	0x00007fff8e021af1 std::locale::_Impl::_Impl(char const*, unsigned long) + 77
12  libstdc++.6.dylib             	0x00007fff8e0212cd std::locale::locale(char const*) + 135
13  libgcu-0.14.0.dylib           	0x00000001084a1274 gcu_value_get_string + 61
14  libgcu-0.14.0.dylib           	0x00000001084a1481 gcu_element_get_weight_as_string + 83
15  libgcugtk-0.14.0.dylib        	0x0000000108447f56 gcu_periodic_set_tips + 329
16  gchemtable                    	0x0000000108418ad7 GChemTableApp::GChemTableApp() + 1077
17  gchemtable                    	0x0000000108417396 main + 82
18  libdyld.dylib                 	0x00007fff951127e1 start + 1

libc++abi.dylib seems to be pulled in by /usr/lib/libstdc++.6.dylib.

[c.herbig@…]

Replying to cal@…:

The crash report seems to indicate it might be related to locale stuff:

Are you using gdb to get the crash report? Whenever I try it I just get useless messages like "No symbol table info available.", even when trying to recompile it and dependencies using --enable-debug or configure.cflags -g.

[c.herbig@…]

I'm going to cross-reference the discussion with the developers here: ​https://savannah.nongnu.org/bugs/?39793

[neverpanic (Clemens Lang)]

Replying to c.herbig@…:

Are you using gdb to get the crash report?

No. This is output generated by Apple's Crash Reporter tool.

[c.herbig@…]

This may be a long shot, but does anybody know how to configure Xcode IDE to work with existing projects through MacPorts? I found these instructions for how to make a new project, ​https://developer.apple.com/library/mac/featuredarticles/UsingMacPorts/_index.html#//apple_ref/doc/uid/TP40010257, but I want to try to set it up to use the existing stuff in this port for better debugging and such. I think the problem is that it needs to set up a target for each of the apps?

[c.herbig@…]

I don't recall seeing this in the log before, but does anyone know what it means, or if it is problematic?

:debug:activate Executing proc-post-org.macports.activate-activate-0
:info:activate 
:info:activate Note that '/opt/local/share' is not in the search path
:info:activate set by the XDG_DATA_HOME and XDG_DATA_DIRS
:info:activate environment variables, so applications may not
:info:activate be able to find it until you set them. The
:info:activate directories currently searched are:
:info:activate 
:info:activate - /opt/local/var/macports/build/_opt_sly_macports_gnome_gnome-chemistry-utils/gnome-chemistry-utils/work/.home/.local/share
:info:activate - /usr/local/share/
:info:activate - /usr/share/
:info:activate 

[c.herbig@…]

Appends notice for broken apps to notes section

[c.herbig@…]

I made a patch that will inform the user, via the notes section, that gchemtable and gchemcalc are currently known to be broken on OS X. The developer does not use OS X, and is unable to identify or replicate the issue. Unfortunately I don't really have anymore time I can put into this right now, and in my humble opinion, gchemcalc and gchemtable are the least important apps in the port; Wolfram|Alpha provides the same information. I'm not seeing anything else wrong with gchempaint, gcrystal, and I don't really have anything to test gspectrum or gchem3D. Unless someone can offer something new, I'm afraid those apps will simply remain broken for now.

[neverpanic (Clemens Lang)]

Replying to c.herbig@…:

I don't recall seeing this in the log before, but does anyone know what it means, or if it is problematic?

I think this message is generated by one of the post-activate update binaries (probably update-desktop-database). Since most software on OS X doesn't use the .desktop files, this should be a non-issue for now.

Replying to c.herbig@…:

I made a patch that will inform the user, via the notes section, that gchemtable and gchemcalc are currently known to be broken on OS X.

r110188, but leaving this open, because it's still valid.

[c.herbig@…]

Despite my apprehension in making my email address public, I have recently volunteered as the maintainer for this port. As such, would it be appropriate to change the ticket status from cc me, to assigned to me?

[mf2k (Frank Schima)]

This port is no longer has a maintainer. See #45189.