横田 宏治 wrote:
> As I think I'd better continue to throw additional informations on this
> problem, I'll do so gradually.
> 

Yes this is a good idea.

First we must locate the reason for the crash.
Is it the format string or the path string. And crashes it really
because of iconv or has it nothing to do with iconv?

Could you copy this

        lyxerr << "LyX: Creating directory %1$s" << endl,
        lyxerr << package().user_support().absFilename() << endl;
        docstring s1 = _("LyX: Creating directory %1$s");
        docstring s2 = from_utf8(package().user_support().absFilename());

        docstring s3 = bformat(_("LyX directory, %1$s. \n"), "/home/dir/");
        docstring s4= bformat(_("LyX directory, %1$s. \n"), 
from_utf8("/home/dir/"));
        docstring s5 = bformat(_("LyX directory, %1$s. \n"),
                                
from_utf8(package().user_support().absFilename()));
        docstring s6 = bformat(_("LyX directory, %1$s. \n"),
                                
from_utf8(package().user_support().absFilename()));
        docstring s7 = bformat(_("You have specified a non-existent user "
                                           "LyX directory, %1$s.\n"
                                           "It is needed to keep your own 
configuration."),
                            from_utf8("/home/dir/"));
        docstring s8 = bformat(_("You have specified a non-existent user "
                                "LyX directory, %1$s.\n"
                                "It is needed to keep your own configuration."),
                            from_utf8(package().user_support().absFilename()));

to the function and check on which line it crashes?

> 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().

So it crashes because of the debugger? I don't know gdb but absfilename
return a std::string, so gdb should know how to handle it.

std::string const absFilename() const { return name_; }
> 
> 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
>>
> 


-- 
Peter Kümmel

Reply via email to