 | 1 | initial version |
The standard 2.4.4 version also crashes on my Snow Leopard VM, with an equally not-as-helpful-as-it-could-be stack trace.
Having changed the build procedure for Wireshark not to strip debug symbols, the most recent 2.4.5-rc0 automated build crashes with a slightly more helpful stack trace; it crashes in _nl_load_domain(), with an abort that seems to indicate some form of internal corruption when trying to read the message catalog.
Stellarium appears to have a similar problem, which nobody appears to have figured out, at least not in that thread.
darktable appears to have a similar problem as well. The bug report doesn't say much; it says it's a duplicate of another bug, where the fix was to recompile libintl.
That last bug points to an Adium bug (I'm pointing to an archived version because that link now gives me a "don't trust this site" warning in Safari and Chrome; apparently it tries to switch to TLS, and gets an out-of-date certificate for *.adium.im, issued by Comodo).
That bug points to a GCC bug, which sounds like a problem with running something built on 10.7 (the Wireshark buildbot is running OS X 10.7) on 10.6. I'll stare at that one a little more.
Please file a bug on this at the Wireshark Bugzilla, so we can 1) track the bug, 2) have it available for others, and 3) record this information in the bug.
| | 2 | No.2 Revision |
The standard 2.4.4 version also crashes on my Snow Leopard VM, with an equally not-as-helpful-as-it-could-be stack trace.
Having changed the build procedure for Wireshark not to strip debug symbols, the most recent 2.4.5-rc0 automated build crashes with a slightly more helpful stack trace; it crashes in _nl_load_domain(), _nl_load_domain(), with an abort that seems to indicate some form of internal corruption when trying to read the message catalog.
Stellarium appears to have a similar problem, which nobody appears to have figured out, at least not in that thread.
darktable appears to have a similar problem as well. The bug report doesn't say much; it says it's a duplicate of another bug, where the fix was to recompile libintl.
That last bug points to an Adium bug (I'm pointing to an archived version because that link now gives me a "don't trust this site" warning in Safari and Chrome; apparently it tries to switch to TLS, and gets an out-of-date certificate for *.adium.im, issued by Comodo).
That bug points to a GCC bug, which sounds like a problem with running something built on 10.7 (the Wireshark buildbot is running OS X 10.7) on 10.6. I'll stare at that one a little more.
Please file a bug on this at the Wireshark Bugzilla, so we can 1) track the bug, 2) have it available for others, and 3) record this information in the bug.
| | 3 | No.3 Revision |
The standard 2.4.4 version also crashes on my Snow Leopard VM, with an equally not-as-helpful-as-it-could-be stack trace.
Having changed the build procedure for Wireshark not to strip debug symbols, the most recent 2.4.5-rc0 automated build crashes with a slightly more helpful stack trace; it crashes in _nl_load_domain(), with an abort that seems to indicate some form of internal corruption when trying to read the message catalog.
Stellarium appears to have a similar problem, which nobody appears to have figured out, at least not in that thread.
darktable appears to have a similar problem as well. The bug report doesn't say much; it says it's a duplicate of another bug, where the fix was to recompile libintl.
That last bug points to an Adium bug (I'm pointing to an archived version because that link now gives me a "don't trust this site" warning in Safari and Chrome; apparently it tries to switch to TLS, and gets an out-of-date certificate for *.adium.im, issued by Comodo).
That bug points to a GCC bug, which sounds like a problem with running something built on 10.7 (the Wireshark buildbot is running OS X 10.7) on 10.6. I'll stare at that one a little more.
Please file a bug on this at the Wireshark Bugzilla, so we can 1) track the bug, 2) have it available for others, and 3) record this information in the bug.
| | 4 | No.4 Revision |
The standard 2.4.4 version also crashes on my Snow Leopard VM, with an equally not-as-helpful-as-it-could-be stack trace.
Having changed the build procedure for Wireshark not to strip debug symbols, the most recent 2.4.5-rc0 automated build crashes with a slightly more helpful stack trace; it crashes in _nl_load_domain(), with an abort that seems to indicate some form of internal corruption when trying to read the message catalog.
Stellarium appears to have a similar problem, which nobody appears to have figured out, at least not in that thread.
darktable appears to have a similar problem as well. The bug report doesn't say much; it says it's a duplicate of another bug, where the fix was to recompile libintl.
That last bug points to an Adium bug (I'm pointing to an archived version because that link now gives me a "don't trust this site" warning in Safari and Chrome; apparently it tries to switch to TLS, and gets an out-of-date certificate for *.adium.im, issued by Comodo).
That bug points to a GCC bug, which sounds like a problem with running something built on 10.7 (the Wireshark buildbot is running OS X 10.7) on 10.6. I'll stare at 10.6.
The way to fix this is to build the support libraries for Wireshark against the Mac OS X 10.6 SDK. We've done that one a little more.
Please file a bug on this at the on the build machine we use for Wireshark Bugzilla, builds; the latest automated builds should work on Snow Leopard (they work on my Snow Leopard VM), so we can 1) track the bug, 2) have it available for others, the next 2.2.x and 3) record this information in the bug.
