Georg Baum wrote: > Peter Kümmel wrote: > >> I've replaced the complete boost tree (.cpp included) with the version >> from trunk. But it also makes no difference. >> >> BTW should we update the 1.4.x tree to boost 1.34? > > Not before it is released. We might want to update to 1.33.1, we had that > for some time without problems in trunk, but as long as 1.32 works I see no > real reason. It was a wild guess that this might be a boost bug, but that > seems not to be the case, and honestly I would be really surprised if it > qwas one, because boost is widely used. > >> I think the reason for the crash is : >> >> lyx-qt3.exe!`anonymous namespace'::`dynamic atexit destructor for >> 'theCuts''() + 0xd bytes C++ msvcr80d.dll!102020c6() >> lyx-qt3.exe!LyXServer::`scalar deleting destructor'() + 0x27 bytes C++ >> msvcr80d.dll!10201e00() >> lyx-qt3.exe!lyx_gui::exit(int status=0) Line 281 + 0xc bytes C++ >> lyx-qt3.exe!QuitLyX(bool noask=false) Line 220 + 0x7 bytes C++ >> >> >> the free variable theCuts, it is destructed first, and I assume the values >> are later on used. > > I don't think so. The backtrace tells about a problem in the destructor, not > in using theCuts. If theCuts would be used after destruction, then the > destructor would not occur in the backtrace, but the code using theCuts > afterwards, no? >
above backtrace was not complete, it only shows the destruction of theCuts the more complete is here: http://www.mail-archive.com/[email protected]/msg101523.html Nevertheless static (global) variables only make problems. >> Because the destruction order is not specified by the >> standard it is possible that we have no problem with gcc. >> >> But it seems the code depends on the order of destruction. >> >> >> I think, when above path really fixes the bug (currently I use the trunk's >> boost) we could also ship the windows binaries. > > I would prefer to understand what the problem is. Your code seems safe, but > your guess does not look right to me. > > > Georg > > -- Peter Kümmel
