Wed 24 Feb 2016 09:05:50 PM UTC, comment #4:
Hmm, this is an odd one. The attached patch avoids the crash for me. But if I move this code into the idx_vector::idx_vector_rep::as_array class (instead of setting the aowner pointer and just generating the output Array on the fly at each call) then I still see a crash. And gdb is saying that the crash is in idx_vector::copy_data but I don't see how that function is being called. The stack trace is strange:
If I set a breakpoint in idx_vector::copy_data execution doesn't stop there before the crash.
So possibly some kind of data overrun is trashing the stack? I don't know.
Running with valgrind shows
That doesn't really give me much of a clue because the data read error doesn't happen until after copy_data is called, and as far as I can tell, it is not supposed to be called at any point from idx_vector::idx_vector_rep::as_array.
(file #36452)
|
Wed 24 Feb 2016 03:31:21 PM UTC, original submission:
When Octave is built with clang (version 3.7) on Debian, I see a segfault from the following simple example (the findobj command is a simplified form of one in print.m that causes the crash):
This is the minimum set of arguments that I've come up with through trial and error that still cause a crash. I don't know if it has to do with the number of args or the specific combination.
Stack trace:
|