Tue 11 May 2010 03:12:09 AM UTC, original submission:
I have attached a file, with which this problem can be reproduced like follows, using the development branch, last updated about two weeks ago. Octave 3.2.3 built with GCC 4.4 does not exhibit this behavior.
GNU Octave, version 3.3.51+
[...]
Octave was configured for "x86_64-apple-darwin10.3.0".
[...]
octave:1> load testing2.oct
octave:2> global Testing
octave:3> save -binary testing.oct
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_S_construct NULL not valid
panic: Abort trap -- stopping myself...
attempting to save variables to `octave-core'...
terminate called recursively
panic: attempted clean up apparently failed -- aborting...
Abort trap
The file starts like this:
# Created by Octave 3.3.51+, Thu May 06 22:16:55 2010 PDT <rajahalm@fiesnra-25221.emea.nsn-net.net>
# name: Testing
# type: global lazy_index
# name: index_value
# type: matrix
# rows: 1
# columns: 1535
964 1535 219 835 350 1028 498 191 1325 538 488 921 381 504 64 251 624 1464 86 853 749 764 476 150 1046 1436 6 466 604 1077 39 1350 1052 484 881 1397 277 1396 1121 ...
gdb backtrace looks like this:
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_S_construct NULL not valid
Program received signal SIGABRT, Aborted.
0x00007fff816eb886 in __kill ()
(gdb) bt
#0 0x00007fff816eb886 in __kill ()
#1 0x00007fff8178beae in abort ()
#2 0x00000001000727a5 in __gnu_cxx::__verbose_terminate_handler ()
#3 0x000000010000516a in __cxxabiv1::__terminate () at ../../../../gcc-4.5.0/libstdc++-v3/src/parallel_settings.cc:35
#4 0x00000001000051c3 in std::terminate () at ../../../../gcc-4.5.0/libstdc++-v3/src/parallel_settings.cc:35
#5 0x0000000100005246 in __cxa_throw () at ../../../../gcc-4.5.0/libstdc++-v3/src/parallel_settings.cc:35
#6 0x000000010001166d in std::__throw_logic_error (__s=<value temporarily unavailable, due to optimizations>) at ../../../../gcc-4.5.0/libstdc++-v3/src/functexcept.cc:62
#7 0x0000000100055761 in std::string::_S_construct<char const*> (__beg=0x0, __end=<value temporarily unavailable, due to optimizations>, __a=<value temporarily unavailable, due to optimizations>) at basic_string.tcc:133
#8 0x0000000100055873 in basic_string (this=0x7fff5fbfd810, __s=0x0, __a=@0x7fff5fbfd81f) at basic_string.h:1648
#9 0x000000010064ebe8 in octave_lazy_index::save_binary ()
#10 0x00000001003f713e in save_binary_data ()
#11 0x00000001003c558f in do_save ()
#12 0x00000001003c9661 in save_vars ()
#13 0x00000001003cae5b in Fsave ()
Relevant part of GCC 4.5 basic_string.tcc:
template<typename _CharT, typename _Traits, typename _Alloc>
template <typename _InIterator>
_CharT*
basic_string<_CharT, _Traits, _Alloc>::
_S_construct(_InIterator __beg, _InIterator __end, const _Alloc& __a,
forward_iterator_tag)
{
#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
if (__beg == __end && __a == _Alloc())
return _S_empty_rep()._M_refdata();
#endif
// NB: Not required, but considered best practice.
if (__gnu_cxx::__is_null_pointer(__beg) && __beg != __end)
__throw_logic_error(__N("basic_string::_S_construct NULL not valid"));
The check on the last three lines does not appear on Apple's version of GCC 4.2.
basic_string.h on and around the line indicated:
template<class _InIterator>
static _CharT*
_S_construct_aux(_InIterator __beg, _InIterator __end,
const _Alloc& __a, __false_type)
{
typedef typename iterator_traits<_InIterator>::iterator_category _Tag;
return _S_construct(__beg, __end, __a, _Tag());
}
So it appears that GCC 4.5 has added some checks for invalid data, that now triggers with lazy_index in binary mode. Ascii saving works, but I'd prefer binary, as my files are already huge.
|