octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ASAN:DEADLYSIGNAL


From: Ben Abbott
Subject: Re: ASAN:DEADLYSIGNAL
Date: Mon, 20 Jun 2016 20:04:31 -0400

On Jun 20, 2016, at 4:42 PM, Dmitri A. Sergatskov <address@hidden> wrote:

On Mon, Jun 20, 2016 at 1:44 PM, Ben Abbott <address@hidden> wrote:
On Jun 20, 2016, at 09:43, Dmitri A. Sergatskov <address@hidden> wrote:

On Mon, Jun 20, 2016 at 7:21 AM, Ben Abbott <address@hidden> wrote:

I’m using Apple’s clang and did hot set -fsanitize. I do not know if other libraries did or if Apple uses -fsanitize by default.

Ben

Dmitri,

Are you suggesting that this is a essentially an ABI problem? Maybe a problem between Apple’s clang and a library built with gcc?

​No. I have no idea is what is going on. But in both cases the error happens when you are building documentation. The octave binary should be built but that time, so you should be able to run
it and experiment with it.

I'm unable to run either the gui or cli.

./run-octave --norc

GEN      doc/interpreter/voronoi.txt
ASAN:DEADLYSIGNAL
=================================================================
==68284==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000040 (pc 0x7fff8d3994cd bp 0x7fff51568360 sp 0x7fff515682e0 T0)

​I seem to remember that mac used to have "dtrace" utility. If ti still does, you can do
dtrace ./run-octave -norc
(there should be some flags to control verbosity)
and see where it breaks.​

Things have changed on MacOS X.  However, it turned out to be fairly simple to modify ./run-octave to use the lldb debugger (“gdb —args” -> “lldb —“). Then “./run-octave -g” put me into the clang debugger.

(lldb) run
Process 66739 launched: '/Users/bpabbott/Development/mercurial/default/sources/src/octave' (x86_64)
ASAN:DEADLYSIGNAL
=================================================================
==66749==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000040 (pc 0x7fff8d3994cd bp 0x7fff5fbfcb40 sp 0x7fff5fbfcac0 T0)
    #0 0x7fff8d3994cc in _pthread_mutex_lock (libsystem_pthread.dylib+0x14cc)
    #1 0x7fff92277be5 in closedir (libsystem_c.dylib+0x25be5)
    #2 0x1027ce418 in octave::sys::dir_entry::open(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) dir-ops.cc:92
    #3 0x1019da729 in octave::sys::dir_entry::dir_entry(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) dir-ops.h:46
    #4 0x1016f177c in genpath(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, string_vector const&) load-path.cc:2146
    #5 0x101545021 in set_image_path(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) defaults.cc:301
    #6 0x10154625f in install_defaults() defaults.cc:455
    #7 0x10000171d in main main-gui.cc:102
    #8 0x7fff875c95c8 in start (libdyld.dylib+0x35c8)
    #9 0x7  (octave-gui)+0x7)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (libsystem_pthread.dylib+0x14cc) in _pthread_mutex_lock
==66749==ABORTING
Process 66739 exited with status = 0 (0x00000000) 

I’m not familiar with Octave’s startup process. Does anyone see something indicative the the problem?

Ben




reply via email to

[Prev in Thread] Current Thread [Next in Thread]