As I think I'd better continue to throw additional informations on this
problem, I'll do so gradually.
Before the call of from_utf8 in lyx_main.C:
> lyxerr << to_utf8(bformat(_("LyX: Creating directory %1$s"),
> from_utf8(package().user_support().absFilename())))
> << endl;
I tried to issue the following command on gdb:
(gdb) print lyx::support::package().user_support().absFilename()
then I got:
> Program received signal SIGSEGV, Segmentation fault.
> 0x2942672a in std::basic_string<char, std::char_traits<char>,
> std::allocator<char> >::basic_string () from
> /usr/local/lib/gcc-4.1.3/libstdc++.so.6
> The program being debugged was signaled while in a function called
> from GDB.
> GDB remains in the frame where the signal was received.
> To change this behavior use "set unwindonsignal on"
> Evaluation of the expression containing the function
> (lyx::support::FileName::absFilename() const) will be abandoned.
Can this related to the problem? However, ordinary execution of the lyx
program issues no problem in getting absFilename() and proceeds to the
evaluation of from_utf8().
Koji
Koji Yokota wrote:
Peter Kümmel wrote:
Could you have a look at the sting passes to boost::basic_format?
support/lstrings.C line 875
OK, it's as follows:
> (gdb) p fmt
> $18 = (const docstring &) @0xbfbfe5a8: {static npos = 4294967295,
> _M_dataplus = {<std::allocator<wchar_t>> =
> {<__gnu_cxx::new_allocator<wchar_t>> = {<No data fields>}, <No data
> fields>}, _M_p = 0x87ebb0c}}
> (gdb) p/c 0xbfbfe5a8
> $19 = -88 '\250'
> (gdb) p arg1
> $20 = (docstring &) @0xbfbfe5a0: {static npos = 4294967295,
> _M_dataplus = {<std::allocator<wchar_t>> =
> {<__gnu_cxx::new_allocator<wchar_t>> = {<No data fields>}, <No data
> fields>}, _M_p = 0x880a20c}}
> (gdb) p/c 0xbfbfe5a0
> $21 = -96 '\240'
So "something" is in both fmt and arg1 (I believe fmt is UCS-4LE format
of string "/home/hge/.lyx-devel". Should this be visible on screen?).
bformat(_("You have specified a non-existent user "
"LyX directory, %1$s.\n"
"It is needed to keep your own configuration."),
No, lyx dies before the function boost::basic_format() returns a value,
i.e. before it evaluates bformat(_( ..., ...)), I think. The trace after
this point seems to go out of lyx sources.
I don't know whether it is useful information or not, but before
bad_format_string() in exception.hpp is called after the above call and
right before crash, maybe_throw_exception() in boost/format/paring.hpp
contains:
boost::io::detail::maybe_throw_exception (exceptions=255 '\377', pos=25,
size=28)
Thanks,
Koji
