LyX svn crashes in _M_attach() on Mac for View>PDF (pdflatex)

[rogermc@…]

Under latest lyx-1.5.0svn:
Start LyX
Open a Lyx file
Select View>PDF (pdflatex)

Spinning ball cursor appears for a while
LyX crashes.

Tail of -dbg any report:

Found file: Web2C 7.5.4
Not a file or we are unable to find it.
Found file: ./NVC_Heine_Model_2.tex
LyXComm: Closing connection
LyXComm: server is disabled, nothing to do
lyx: Server socket quitting

lyx: SIGSEGV signal caught
Sorry, you have found a bug in LyX. Please read the bug-reporting instructions in Help->Introduction
and send us a bug report, if necessary. Thanks !
Bye.
Abort trap

[Juergen Spitzmueller]

a few questions:

• does it crash on any LyX file or on specific ones?
• do these LyX files contain graphics?
• does the crash go away if you switch off the converter cache (in

Preferences->Converters)?

[rogermc@…]

Crashed on two different LyX files.
No graphics in files, plenty of math blocks and some tables.

Currently reinstalling with different configuration, I will try turning off the converter cache later.

[rogermc@…]

First attempt with a file that crashed before crashed again.
Tried a different file (maybe from earlier LyX version), no crash.
Tried the file that crashed, this time no crash!

Configured with:
./configure --prefix=/Applications/"LyX.app" --with-version-suffix=-1.5 --without-x --with-qt4-dir=/
usr/local/Trolltech/Qt-4.2.2 --with-included-gettext --enable-optimization=-Os --enable-debug --
enable-assertions

I'll try the same files again without --enable-debug --enable-assertions
If I can get the crash to repeat I'll try disabling the cache.

[rogermc@…]

IGNORE Comment 3.
I accidently used RC2 instead of the svn version!

[rogermc@…]

Stiil crashes with Preferences>Converters>Converter File Cache check-box unchecked (i.e. disabled).

It doesn't seem to crash with the configure --disable-stdlib-debug option (Bennet's advice which seems
consistent with my experience).

[Juergen Spitzmueller]

could you upload a test file that triggers the crash for you and provide a
backtrace?

[Juergen Spitzmueller]

The file doesn't crash for me.

[rogermc@…]

Very simple file that crashes

[Juergen Spitzmueller]

what does -dbg depend reveal?

[Juergen Spitzmueller]

patch for debugging

[rogermc@…]

-dbg depend result:

QObject::moveToThread: Current thread (0x12b37ab0) is not the object's thread (0x12b1c710).
Cannot move to target thread (0x12b1c710)

Menu warning: menu entry "Plain Text..." does not contain shortcut `A'.
QObject::moveToThread: Current thread (0x12b37ab0) is not the object's thread (0x12b1c710).
Cannot move to target thread (0x12b1c710)

QObject::moveToThread: Current thread (0x12b37ab0) is not the object's thread (0x12b1c710).
Cannot move to target thread (0x12b1c710)

QObject::moveToThread: Current thread (0x12b37ab0) is not the object's thread (0x12b1c710).
Cannot move to target thread (0x12b1c710)

QObject::moveToThread: Current thread (0x12b37ab0) is not the object's thread (0x12b1c710).
Cannot move to target thread (0x12b1c710)

Dependency file does not exist, or has wrong format
Found file: Web2C 7.5.4
Not a file or we are unable to find it.
Found file: ./Test_-_very_simmple.tex

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x730b04bf
boost::shared_ptr<boost::re_detail::basic_regex_implementation<char, boost::regex_traits<char,
boost::cpp_regex_traits<char> > > >::swap (this=0x730b04bf, other=@0x5fb81000) at /usr/include/
c++/4.0.0/bits/stl_algobase.h:97
97 const _Tp tmp = a;
(gdb)

[rogermc@…]

Large file including graphics did not crash with patch for debugging applied.
I checked a few other files also without crashing.

[Juergen Spitzmueller]

another debugging patch

[rogermc@…]

Without -dbg, crashed with no console output after View>PDF

With -dbg latex console output ended with:

Log line: PDF statistics:
Log line: 7 PDF objects out of 300000
Log line: 0 named destinations out of 131072
Log line: 1 words of extra memory for PDF output out of 65536
Log line: </sw/var/lib/texmf/fonts/pk/ljfour/jknappen/ec/ecrm1000.600pk> </sw/var/
Log line: lib/texmf/fonts/pk/ljfour/jknappen/ec/ecrm1200.600pk> </sw/var/lib/texmf/fonts/
Log line: pk/ljfour/jknappen/ec/ecrm1728.600pk>
Log line: Output written on Test_-_very_simmple.pdf (1 page, 9001 bytes).
Log line:
Scanning aux file: /private/tmp/lyx_tmpdir14545WNssgP/lyx_tmpbuf0/Test_-_very_simmple.aux

lyx: SIGSEGV signal caught
Sorry, you have found a bug in LyX. Please read the bug-reporting instructions in Help->Introduction
and send us a bug report, if necessary. Thanks !
Bye.
Abort trap

[rogermc@…]

This appears to be a bug in boost, not LyX.
This problem does not occur with LyX1.0.5rc2.

The boost regex constructor appears to be having trouble with:
static regex unwanted("^{.*
.(aux|log|dvi|bbl|ind)$")
in handleFoundFile of LaTeX.cpp}

Other regex declarations appear to work OK.

The following debugging modifications to basic_regex indicate that, for the declaration of unwanted,
assign(p, f) fails to return (see terminal output extract below):

explicit basic_regex(const charT* p, flag_type f = regex_constants::normal)
{

std::cout << "basic_regex constructor, p:" << p <<std::endl;

assign(p, f);

std::cout << "basic_regex constructor assigned, p:" << p <<std::endl;

}

End of terminal output for src/lyx -dbg depend,following View>PDF (pdflatex)

...
basic_regex constructor, p:Writing nomenclature file (.+).*
basic_regex constructor assigned, p:Writing nomenclature file (.+).*
basic_regex constructor, p:
tf@toc=
write.*
basic_regex constructor assigned, p:
tf@toc=
write.*
basic_regex constructor, p:.*\([^{)]+.*
basic_regex constructor assigned, p:.*\([})]+.*
basic_regex constructor, p:\(([^{()]+)(.).*
basic_regex constructor assigned, p:\(([}()]+)(.).*
Found file: Web2C 7.5.4
basic_regex constructor, p:^{.*\.(aux|log|dvi|bbl|ind)$}

lyx: SIGSEGV signal caught
Sorry, you have found a bug in LyX. Please read the bug-reporting instructions in Help->Introduction
and send us a bug report, if necessary. Thanks !
Bye.
Abort trap

[rogermc@…]

Some debugging results.

assign(p, f) in basic_regex does not appear to be able to handle the | symbol in

static regex unwanted("^{.*
.(aux|log|dvi|bbl|ind)$");
which:
Works with "}.*
.$"
Crashes with "^{.*
.(aux|log|dvi|bbl|ind)"
Crashes with "}.*
.(aux|log)$"
Crashes with "^{.*
.(dvi|bbl|ind)$"
Crashes with "}.*
.(dvi|bbl)$"
Works with "^{.*
.(dvi)$"
Works with "}.*
.(bbl)$"

[rogermc@…]

Re previous commnet 17, note that backtrace (Comment 7) shows crash from do-assign.

[rogermc@…]

Here is a more extensive backtrace that I got using gdb:

(gdb) bt
#0 0x1396c288 in gnu_debug::_Safe_iterator_base::_M_attach ()
#1 0x006cc33b in gnu_debug::_Safe_iterator<gnu_cxx::normal_iterator<int const*,
gnu_norm::vector<int, std::allocator<int> > >, gnu_debug_def::vector<int, std::allocator<int> >

::_Safe_iterator<gnu_cxx::normal_iterator<int*, gnu_norm::vector<int, std::allocator<int> > >

(this=0xbfffb334, x=@0xbfffb348) at /usr/include/c++/4.0.0/debug/safe_base.h:96

#2 0x0072b4a7 in gnu_debug::_Safe_iterator<gnu_cxx::normal_iterator<int*,
gnu_norm::vector<int, std::allocator<int> > >, gnu_debug_def::vector<int, std::allocator<int> >

::_M_can_advance (this=0xbfffb924, n=@0xbfffb62c) at /usr/include/c++/4.0.0/debug/

safe_iterator.tcc:55
#3 0x0072b5ad in gnu_debug::_Safe_iterator<gnu_cxx::normal_iterator<int*,
gnu_norm::vector<int, std::allocator<int> > >, gnu_debug_def::vector<int, std::allocator<int> >

::operator-= (this=0xbfffb924, n=@0xbfffb94c) at /usr/include/c++/4.0.0/debug/safe_iterator.h:

290
#4 0x0072b705 in gnu_debug::_Safe_iterator<gnu_cxx::normal_iterator<int*,
gnu_norm::vector<int, std::allocator<int> > >, gnu_debug_def::vector<int, std::allocator<int> >

::operator- (this=0xbfffb938, n=@0xbfffb94c) at /usr/include/c++/4.0.0/debug/safe_iterator.h:

301
#5 0x0072b863 in gnu_debug_def::vector<int, std::allocator<int> >::pop_back (this=0xbfffbb14) at
/usr/include/c++/4.0.0/debug/vector:248
#6 0x00731cf0 in boost::re_detail::basic_regex_parser<char, boost::regex_traits<char,
boost::cpp_regex_traits<char> > >::unwind_alts (this=0xbfffbab8, last_paren_start=336) at ../boost/
boost/regex/v4/basic_regex_parser.hpp:2096
#7 0x007327a5 in boost::re_detail::basic_regex_parser<char, boost::regex_traits<char,
boost::cpp_regex_traits<char> > >::parse_open_paren (this=0xbfffbab8) at ../boost/boost/regex/v4/
basic_regex_parser.hpp:406
#8 0x00734e8e in boost::re_detail::basic_regex_parser<char, boost::regex_traits<char,
boost::cpp_regex_traits<char> > >::parse_extended (this=0xbfffbab8) at ../boost/boost/regex/v4/
basic_regex_parser.hpp:258
#9 0x0071dd10 in boost::re_detail::basic_regex_parser<char, boost::regex_traits<char,
boost::cpp_regex_traits<char> > >::parse_all (this=0xbfffbab8) at ../boost/boost/regex/v4/
basic_regex_parser.hpp:187
#10 0x00838bda in boost::re_detail::basic_regex_parser<char, boost::regex_traits<char,
boost::cpp_regex_traits<char> > >::parse (this=0xbfffbab8, p1=0x5fc148 "^{.*
.(aux|log|dvi|bbl|ind)
$", p2=0x5fc163 "", l_flags=0) at ../../../../boost/boost/regex/v4/basic_regex_parser.hpp:129
#11 0x00838d68 in boost::re_detail::basic_regex_implementation<char, boost::regex_traits<char,
boost::cpp_regex_traits<char> > >::assign (this=0x1c0bd070, arg_first=0x5fc148 "}.*
.(aux|log|dvi|
bbl|ind)$", arg_last=0x5fc163 "", f=0) at ../../../../boost/boost/regex/v4/basic_regex.hpp:100
#12 0x001ace3c in boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char>

::do_assign (this=0xd74e90, p1=0x5fc148 "^{.*
.(aux|log|dvi|bbl|ind)$", p2=0x5fc163 "", f=0)}

at ../../../../boost/boost/regex/v4/basic_regex.hpp:537
#13 0x0071fc8a in boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char>

::assign (this=0xd74e90, p=0x5fc148 "^{.*
.(aux|log|dvi|bbl|ind)$", f=0) at ../boost/boost/regex/}

v4/basic_regex.hpp:262
#14 0x007216cf in boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char>

::basic_regex (this=0xd74e90, p=0x5fc148 "^{.*
.(aux|log|dvi|bbl|ind)$", f=0) at ../boost/boost/}

regex/v4/basic_regex.hpp:215
#15 0x00066371 in lyx::(anonymous namespace)::handleFoundFile (ff=@0xbfffc0cc,
head=@0xbfffc2ac) at LaTeX.cpp:867
#16 0x00068e5c in lyx::LaTeX::deplog (this=0xbfffc4a0, head=@0xbfffc2ac) at LaTeX.cpp:1074
#17 0x000699a5 in lyx::LaTeX::run (this=0xbfffc4a0, terr=@0xbfffc51c) at LaTeX.cpp:281
#18 0x000372a5 in lyx::Converters::runLaTeX (this=0x1811d444, buffer=@0x1c08dcf0,
command=@0xbfffc900, runparams=@0xbfffc790, errorList=@0x1c0b8414) at Converter.cpp:617
#19 0x00039ef4 in lyx::Converters::convert (this=0x1811d444, buffer=0x1c08dcf0,
from_file=@0xbfffcc7c, to_file=@0xbfffcca4, orig_from=@0xbfffcc74, from_format=@0xbfffccc8,
to_format=@0xbfffd66c, errorList=@0x1c0b8414, conversionflags=0) at Converter.cpp:396
#20 0x0004ec2d in lyx::Exporter::Export (buffer=0x1c08dcf0, format=@0xbfffd66c,
put_in_tempdir=true, result_file=void) at Exporter.cpp:219
#21 0x0004f605 in lyx::Exporter::preview (buffer=0x1c08dcf0, format=@0xbfffd66c) at Exporter.cpp:
277
#22 0x0008d62f in lyx::LyXFunc::dispatch (this=0x1811d3a0, cmd=@0x17882558) at LyXFunc.cpp:
930

[rogermc@…]

In file basic_regex_parser.hpp

In
bool basic_regex_parser<charT, traits>::unwind_alts(std::ptrdiff_t last_paren_start)

The instruction that fails is:
m_alt_jumps.pop_back();

[Uwe Stöhr]

Stefan, could you perhaps help us here?

[rogermc@…]

Progress report.

I am using the Xcode debugger (which provides a GUI for gdb).
I tried a short test program that invokes std::vector.pop_back.
The test program doesn't crash.
The test program automatically linked (due to Xcode build) so that unwind_alts m_alt_jumps.pop_back
invokes pop_back from /Developer/SDKs/MacOSX 10.4u.SDK/usr/include/c++/4.0.0/bits/stl_vecor

void

pop_back()
{

--this->_M_impl._M_finish;
this->_M_impl.destroy(this->_M_impl._M_finish);

}

Under the LyX build, m_alt_jumps.pop_back() of basic_regex_parser.hpp invoked /usr/include/c++/
4.0.0/debug/vector

void

pop_back()
{

glibcxx_check_nonempty();
iterator victim = end() - 1;
victim._M_invalidate();
_Base::pop_back();

}

The crash appears to occur in or on return from glibcxx_check_nonempty.
The descent into glibcxx_check_nonempty is torturous and I can't get a clue as to what its doing!

I'm now going to see what happens with the configure --disable-stdlib-debug option as this prevents
the crash.

[rogermc@…]

Configuring with --disable-stdlib-debug, no crash occurs and

m_alt_jumps.pop_back invokes pop_back from /usr/include/c++/4.0.0/bits/stl_vector
which is the same pop_back procedure invoked by my pop_back test program.

It seems that there is something wrong with the stdlib-debug code that pop_back invokes?

I hope Stefan can shed some light on what's going on here.

Obviously we could close our eyes to this problem by configuring with --disable-stdlib-debug, but it
would be much better if the problem could be solved.

[sts@…]

I had spent some time on this before, but didn't find the reason, just very very odd behaviour as described.
Maybe it's some memory corruption or even a compiler error. Will look into it today or tomorrow again.

[sts@…]

Tried now again with trunk on Mac, and I cannot get it to crash. I remember having had this crash before,
maybe some months ago. It could be that it went away when I switched to cmake, just a guess.

[rogermc@…]

I just did an svn update.
lyx-1.5.0svn no longer crashes

My previous update (the version that crashed) was about 13 July so whatever caused the crash seems to
have been "fixed".

[rogermc@…]

Last comment invalid!

My previous build must have been with --disable-stdlib-debug.

I just rebuilt without --disable-stdlib-debug and it still crashes.

I also tried building lyx-1.5.0rc2 without --disable-stdlib-debug; it does NOT crash.

[rogermc@…]

I think that I have discovered why rc2 does not crash while svn crashes.

Configuration command for rc2 as recorded in rc2 config.log:

$ ./configure --prefix=/Applications/LyX.app --with-version-suffix=-1.5 --without-x --with-

frontend=qt4 --with-qt4-dir=/usr/local/Trolltech/Qt-4.2.2 --with-included-gettext --enable-
optimization=-Os --enable-debug --enable-assertions

Configuration command for svn as recorded in svn config.log:
$ ./configure --prefix=/Applications/LyX.app --with-version-suffix=-1.5 --without-x --with-qt4-
dir=/usr/local/Trolltech/Qt-4.2.2 --with-included-gettext --enable-optimization=-Os --enable-
debug --enable-assertions

As can be seen, neither includes --disable-stdlib-debug.
However, for basic_regex_parser<charT, traits>::unwind_alts
for the instruction m_alt_jumps.pop_back()

for rc2 the call to pop_back is linked to pop_back in /usr/include/c++/4.0.0/bits/stl_vector.h
whereas, for svn, the call to pop_back is linked to pop_back in /usr/include/c++/4.0.0/debug/vector

It seems that the rc2 and svn configure processes are generating different linkages
such that stdlib-debug is automatically enabled for svn but disabled for rc2?

[Georg Baum]

fixing this in 1.5.0 is not possible anymore.

[rogermc@…]

I have been doing a lot of research into this.
I don't believe the problem is with Lyx.
It is due to
gnu_debug::_Safe_iterator_base::_M_attach ()
crashing under infrequent circumstances and is not restricted to the scenario initially reported for tis
bug.
M_attach () crashes have occurred under other circumstances both with LyX and with other programs as
revealed by web search. This seems to cause lots of wasted effort in people trying to fix their programs
when their problem is probably not theirs but a _M_attach () problem.

It is possible that a boost routine is passing it something to _M_attach () that it shouldn't but I doubt it.

So far I haven't been able to identify the specific circumstances under which _M_attach () crashes.
Perhaps something should be reported to whoever is responsible for _M_attach ().

An earlier bug in _M_attach () was reported and fixed at
​http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17664

A small test program is needed to demonstrate _M_attach () crashing.

[lasgouttes]

Impressive debugging work, Roger! The only information I can give is,
concerning comment 28, that indeed stdlib-debug is disabled by default in
relelases and prereleases.

[lasgouttes]

1.5.1 is an emergency relelase. Moving all to 1.5.2

[rogermc@…]

I finally got a simple test program going with the boost routines compiled and built under Xcode.
Debugging demonstrated that it had built with stdlib debug enabled.
It did NOT crash, I stepped the debugger through the pop-back call that was failing with LyX
and satisfied myself that it was following the path through to the _M_attach call that was crashing.

So maybe the problem is with LyX after all?

In the test program below, LyX calls equivalent to tests 2 and 3 crash.
What's the nextstep? I have absolutely no idea!
Now that I have a better understanding of Xcode, maybe I should try and build a test program that uses
the actual boost libraries.

LyX instruction in Latex.cpp that crashes:

static regex unwanted("^{.*
.(aux|log|dvi|bbl|ind)$");}

Test program

#include <regex.hpp>

#include <iostream>

int main (int argc, char * const argv[])
{
using namespace boost;
regex is defined in boost/regex/v4/regex.hpp and regex_fwd.hpp as
typedef basic_regex<char, regex_traits<char> > regex

static boost::regex test1("test");

static boost::regex test2("(a|b)");
for (int index = 1; index < 100; index++)

{
static boost::regex test3("^{.*
.(aux|log|dvi|bbl|ind)$");
}}

return 0;

}

[rogermc@…]

Copy of previous test program rebuilt without boost lib routines but linked with boost libraries.

Program did NOT crash.
However, boost source code did not seem to be properly synchronized with libraries so could not
conclusively check whether or not the stdlib debug code was being executed. I don't seem to be able to
always get into the pop_back routine with the debugger (this was no problem with the previous non-
boost-library test program). When I do manage to, the debugger shows stl not debug code.
Indications were that stdlib debug code wasn't being executed which seems strange as, presumably, the
same boost libraries are being used by the LyX debug build which certainly does execute the stdlib debug
code as revealed by gdb backtrace following a LyX crash.

[Juergen Spitzmueller]

Roger, have you tried if trunk (1.6svn) triggers the crash as well? There has
been an update of the boost libraries there.

[rogermc@…]

Subject: Re: LyX svn crashes in _M_attach() on Mac for View>PDF (pdflatex)

Thanks for the suggestion.
I'm currently updating, but I don't think I'm updating from trunk and
don't have much idea of how to use svn.
A colleague set me up to update from the 1.5x branch I think.

Can you tell me how to update from trunk instead.

I've pretty much come to a dead end trying to solve this bug.
I have a go at it from time to time and am down to tracking through
assembler code.
More of a very slow learning process than real debugging.
It is certainly a solid bug on my system in that the crash continues
to occur in the same place despite updates and me messing around with
stl routines by breaking instructions down to their individual elements.

The make of the latest update has just failed with:

libtool: link: `frontends/qt4/libqt4.la' is not a valid libtool archive
make[3]: * [lyx-qt4] Error 1
make[2]: * [all-recursive] Error 1
make[1]: * [all] Error 2
make: * [all-recursive] Error 1

Any ideas on this?

Regards
Roger

On 29/08/2007, at 7:29 PM, bugzilla-daemon@… wrote:

#4014

---

11:29 -------
Roger, have you tried if trunk (1.6svn) triggers the crash as well?
There has
been an update of the boost libraries there.

---

You reported the bug, or are watching the reporter.

[rogermc@…]

Yuk! My previous long-winded Comment 36 was supposed to go to Juergen via e-mail, not Bugzilla.

I've just noticed that the Severity of this bug has been set to critical.
I'm not sure that the severity is really that great as the failure occurs only in the processing of an
additional debug component that is added to vectors by stdlib-debug and is absent in the release
version of LyX and so should not occur for LyX "customers".

I have tried introducing vector associated errors to exercise the debug capabilities of stdlib-debug and
have always been appropriately rebuked by messages from stdlib-debug, so the debug functions seem to
normally work when they're supposed to without crashing the program.

[rogermc@…]

LyX 1.6.0svn does not crash.

From config.log:
Configure command:
./configure --prefix=/Applications/LyX.app --with-version-suffix=-1.5 --without-x --with-qt4-dir=/
usr/local/Trolltech/Qt-4.2.2 --with-included-gettext --enable-optimization=-Os --enable-debug --
enable-assertions

From config.h:
/* libstdc++ debug mode */
#define _GLIBCXX_DEBUG 1

/* libstdc++ pedantic debug mode */
#define _GLIBCXX_DEBUG_PEDANTIC 1

So it looks the stdlib debug code is being included and no crash is occurring.
I'll look into a bit further to be absolutely sure but, hopefully, the bug has gone.

[rogermc@…]

LyX 1.6.0svn does not suffer from this bug.

Using the debugger, I have stepped through the code that previously failed without any problems.

[Juergen Spitzmueller]

OK, I'm marking this bug then fixed for 1.6.
For 1.5, we consider updating boost as well.

[Juergen Spitzmueller]

I just updated boost in 1.5.2svn.
Could you test if this solved the bug, Roger?

[rogermc@…]

Unfortunately problem remains with 1.5.2.
1.6svn with latest svn update still works.

I tried completely removing the boost folder, then svn update and make distclean but same problem.

As a desperation step I will try replacing the 1.5.2 boost folder with a copy of the 1.6 boost folder but I
don't expect any change.

This bug is frustatingly subtle!

gdb terminal output gives same result as before:

Found file: ./newfile1.tex

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x4d9b04bf
boost::shared_ptr<boost::re_detail::basic_regex_implementation<char, boost::regex_traits<char,
boost::cpp_regex_traits<char> > > >::swap (this=0x4d9b04bf, other=@0x5ffba000) at /usr/include/c
++/4.0.0/bits/stl_algobase.h:97
97 const _Tp tmp = a;
(gdb) bt
#0 boost::shared_ptr<boost::re_detail::basic_regex_implementation<char, boost::regex_traits<char,
boost::cpp_regex_traits<char> > > >::swap (this=0x4d9b04bf, other=@0x5ffba000) at /usr/include/c
++/4.0.0/bits/stl_algobase.h:97
#1 0x001ae22c in boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char>

::do_assign (this=0x5ffba000, p1=0x5ffbbb00 <Address 0x5ffbbb00 out of bounds>, p2=0x0,

f=1357466880) at ../../../../boost/boost/regex/v4/basic_regex.hpp:525
#2 0xd6b6b000 in ?? ()
Cannot access memory at address 0x71afbebf
Previous frame inner to this frame (corrupt stack?)

[rogermc@…]

I tried replacing the 1.5.2 boost folder with a copy of the 1.6 boost folder and discovered what seems a
major differance.

The 1.6 boost/libs folder contains no Makefile.in or Makefile.am
Consequently no boost libs are built.
Nevertheless, 1.6 builds and runs OK.

When I try to autogen 1.5.2, autogen fails with:

Building Makefile templates...

.

configure.ac:457: required file `boost/libs/Makefile.in' not found
configure.ac:457: required file `boost/libs/filesystem/Makefile.in' not found
configure.ac:457: required file `boost/libs/filesystem/src/Makefile.in' not found
configure.ac:457: required file `boost/libs/iostreams/Makefile.in' not found
configure.ac:457: required file `boost/libs/iostreams/src/Makefile.in' not found
configure.ac:457: required file `boost/libs/regex/Makefile.in' not found
configure.ac:457: required file `boost/libs/regex/src/Makefile.in' not found
configure.ac:457: required file `boost/libs/signals/Makefile.in' not found
configure.ac:457: required file `boost/libs/signals/src/Makefile.in' not found
boost/Makefile.am:15: MONOLITHIC_BOOST does not appear in AM_CONDITIONAL
done.
Building configure...

.

done.

run "./configure ; make"

When I run configure, it fails because of the lack of boost/libs Makefiles.

Running svn update does not restore the missing boost/libs Makefile.in and Makefile.am

[Juergen Spitzmueller]

I tried replacing the 1.5.2 boost folder with a copy of the 1.6 boost folder
and discovered what seems a major differance.

Yes, in 1.6, the building of boost was changed, therefore you cannot just copy
that folder. That should not have any effect on this bug, though.

Does it build if you use boost from 1.5.2svn?

[rogermc@…]

It builds using 1.5.2svn boost from URL: ​svn://svn.lyx.org/lyx/lyx-devel/branches/BRANCH_1_5_X but
stills exhibits the same failure with View>PDF (pdflatex) whereas View>PDF (pdflatex) works with
1.6svn.
Where I've used 1.5.2 boost in the preceding Comments from #42 onwards I should have stated
1.5.2svn boost.

I attempted to use 1.6svn boost in 1.5.2svn just to see if I could understand why View>PDF (pdflatex)
worked in 1.6svn but failed under 1.5.2svn. Also to be provide more evidence that boost is causing the
problem.

"Yes, in 1.6, the building of boost was changed" suggests that the "change" may have been responsible,
in 1.6svn, for overcoming the problem that I have with View>PDF (pdflatex) under 1.5.2svn.

In the mean-time I've restored boost from 1.5.2svn and am rebuilding.

[Juergen Spitzmueller]

"Yes, in 1.6, the building of boost was changed" suggests that the "change"
may have been responsible, in 1.6svn, for overcoming the problem that I have
with View>PDF (pdflatex) under 1.5.2svn.

Very unlikely. The more so as this change happened _after_ you confirmed that
1.6 doesn't have the bug. I really do not understand why 1.6 works and 1.5
doesn't. You don't use different compilers or compiler option to build the two,
do you?

[rogermc@…]

I use exactly the same export LDFLAGS, autogen.sh and configure cammands to build both 1.5.2svn and
1.6svn.

[rogermc@…]

I have now managed to build a version of 1.5.2svn with the 1.5.2svn boost directory replaced by the
1.6svn boost directory.
Apart from replacing the boost directory, the only other changes I have made have been to configure.ac
and various Makefile.am to account for the different structure of 1.6svn boost.

This version does not crash and does produce a PDF document under View>PDF (pdflatex).

[Juergen Spitzmueller]

can you post the output of "svn diff boost", please?

[rogermc@…]

Is this what you want?
Its from the directory that I copied from my lyx-devel to try out the boost diirectory replacement.

I think I made these particular changes due to automake complaining about MONOLITHIC_BOOST not
being defined somewhere (and assuming that three times slower would be better then never).

Last login: Sat Sep 15 16:22:14 on ttyp1
Welcome to Darwin!
:~ Roger$cd /Applications/lyx-devel1.5:/Applications/lyx-devel1.5

Roger$svn diff boost

Index: boost/Makefile.am
===============================================================
====
--- boost/Makefile.am (revision 20278)
+++ boost/Makefile.am (working copy)
@@ -12,15 +12,15 @@

# This version is more than three times faster than the one below

-if MONOLITHIC_BOOST
+#if MONOLITHIC_BOOST

-liblyxboost_la_SOURCES = \

• lyxboost.cpp \
• libs/regex/src/instances.cpp \
• libs/regex/src/cpp_regex_traits.cpp \
• libs/regex/src/c_regex_traits.cpp

+#liblyxboost_la_SOURCES = \
+# lyxboost.cpp \
+# libs/regex/src/instances.cpp \
+# libs/regex/src/cpp_regex_traits.cpp \
+# libs/regex/src/c_regex_traits.cpp

-else
+#else

liblyxboost_la_SOURCES = \

\

@@ -53,4 +53,4 @@

libs/signals/src/slot.cpp \
libs/signals/src/trackable.cpp

-endif
+# endif
:/Applications/lyx-devel1.5 Roger$

[Juergen Spitzmueller]

OK, I went through the whole story again.
I try to summarize:
1.5svn crashes (with stdlib-debug enabled), while 1.6svn doesn't. The only
difference (after the boost upgrade) is the build procedure, which was changed
in trunk here:
​http://www.lyx.org/trac/changeset/19410
​http://www.lyx.org/trac/changeset/19417
​http://www.lyx.org/trac/changeset/19521
​http://www.lyx.org/trac/changeset/19522
​http://www.lyx.org/trac/changeset/19527
​http://www.lyx.org/trac/changeset/19532
​http://www.lyx.org/trac/changeset/19869

So either we backport these changes (I'm a bit reluctant to do this) or we just
have to live with this problem and mark the bug WONTFIX. Since the crash only
occurs with stdlib-debug enabled (which is not the case in releases), I'm
tempted to do the latter.

[rogermc@…]

I think that is the right approach for 1.5.
I don't think it makes any sense to backport your changes.
WONTFIX makes sense for 1.5
But, as it seems to work for 1.6svn, couldn't you change the Target Milestone to 1.6?
Irrespective, I'll check it occassionally in case it mysteriously fixes itself.

I've never looked at changesets before, so I might be quite wrong here.
As you imply, the Changesets seem only to apply to trunk (1.6svn), not to 1.5svn.
Looking for example at Changeset 19410 its Message states "also combine boost stuff into a single
library" which can be seen in trunk's boost directory but not in the 1.5svn.
So, to me, it doesn't make sense to backport changes from 1.6svn which works because of something
that doesn't work in 1.5svn. But maybe I've misunderstood something.
I have a suspicion (not well-founded, except from past mysterious experiences) that there is a remote
chance that whatever has occurred in "combine boost stuff into a single library" may have fortuitously
fixed the problem. {Then again, maybe not!)

[Juergen Spitzmueller]

OK, WONTFIX for 1.5.
Please leave this report open unless 1.6.0 is released.
Thanks again, Roger, for all your testing.

[rogermc@…]

Problem finally found to be due to boost/libs/regex/src precompiled headers.

The problem no longer occurs when all lines of boost/libs/regex/src/pch.h are commented out.
I could not identify any particular header file causing the problem.
The bug is only cured by commenting out ALL headers in boost/libs/regex/src/pch.h.

gcc version:
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5363)

diff:
Index: pch.h
===============================================================
====
--- pch.h (revision 20368)
+++ pch.h (working copy)
@@ -1,3 +1,6 @@
+/*
+Precompiled header compilation commented out RMCM 20Sep07
+to prevent View>PDF (pdflatex) failure (#4014)

#include <cctype>
#include <climits>
#include <clocale>

@@ -12,3 +15,4 @@

#include <ostream>
#include <set>
#include <stdexcept>

+*/

[Juergen Spitzmueller]

Well spotted.
Can you send this to the devel list, please? I'm not very familiar with this
pch stuff, so I cannot really judge whether you patch makes sense.

[rogermc@…]

As this appears to be a gcc problem concerned with building the boost regex library I've changed the
Component setting to "build".

[lasgouttes]

Fixed in branch now. Roger, if something is still wrong, feel free to reopen.

URL: ​http://www.lyx.org/trac/changeset/20409
Log:

• pch.h: make sure that config.h is read (#4014)