core dump on 'insert->graphics'

[laurent.charles@…]

Lyx crashes systematically on 'insert->graphics', even with an empty newly
created document.
It occurs both with qt and xform front ends.

NB: Only configure option is '--prefix=' and '--with-frontend=qt' in one case.

[levon]

Obviously, we need more info than this. Do you think we'd make
a release where this happens for everybody ?

[levon]

reporter says :

I reproduce the problem on Sparc/Solaris8 (gcc 2.95.3 + binutils 2.13.2)
but not for Linux Debian/Woody.

Here is what I did to compile:

tar -xzf lyx-1.3.0.tar.gz
cd lyx-1.3.0
./configure --prefix=/local/cl22/test-lyx
make
make install

I then run lyx:

/local/cl22/test-lyx/bin/lyx

I simply create a new document: 'File->New',
and insert a graphics: 'Insert->Graphics'
Lyx opens the box, wait about 2 seconds, and coredumps...
Here is the message:

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 !
LyX: Attempting to save document newfile1.lyx

/home/cl22/newfile1.lyx.emergency

Save seems successful. Phew.

Bye.
Abort (core dumped)

gdb -core core + 'bt' gives:

(gdb) bt
#0 0xfed9c840 in ?? ()
#1 0x004aa510 in ?? ()
#2 0x000ff6ac in ?? ()
#3 0xfed9b86c in ?? ()
#4 0x0050c624 in ?? ()
#5 0x00486128 in ?? ()
#6 0x0048570c in ?? ()
#7 0x004849e8 in ?? ()
#8 0x0049452c in ?? ()
#9 0x0049481c in ?? ()
#10 0x0001e5c8 in ?? ()
#11 0x002ceb64 in ?? ()
#12 0x00375ae0 in ?? ()

Which does not help much... :-{

I tried to recompile with --enable-debug in configuration to have more
information, but it does not change anything to the debug output...

[levon]

You must make clean and rebuild before you get a useful backtrace.

What xforms version ? What does lyx -dbg graphics say ? Attach the
problematic image.

This might be a compiler backend bug or something ...

[laurent.charles@…]

xforms version: 0.89.0

I compiled & installed lyx (1.3.0) in a specific directory '/tmp/cl22/test-lyx'
to reproduce the problem.
I run '/tmp/cl22/test-lyx/bin/lyx -dbg any 2>lyx.log'
The lyx.log file is attached
I do:

• create new document
• insert -> graphics

The coredump occurs about 2 sec after the open file dialog box is displayed.

[levon]

Laurent's log file says this :

The file is not readable

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 !
LyX: Attempting to save document newfile1.lyx

/users/cl22/newfile1.lyx.emergency

Save seems successful. Phew.

Bye.

I can't reproduce any crash still. I'm not sure what's going on. Angus ?

There's only one other possibly relevant bit :
Calling BC refresh()
FormGraphics::updateBB() [no BoundingBox]
[readBB_from_PSFile] no(e)ps-format
Calling BC refresh()

[laurent.charles@…]

Lyx logfile until crash

[leeming]

Here's my take on it (guess work only of course).

Problem 1 is that lyx can't find the file. This is the block of code that prints
that error message.
void CacheItem::Impl::convertToDisplayFormat()
{

setStatus(Converting);

First, check that the file exists!
if (IsFileReadable(filename_)) {

if (status_ != ErrorNoFile) {

setStatus(ErrorNoFile);
lyxerr[Debug::GRAPHICS]

<< "\tThe file is not readable" << endl;

}
return;

}

Problem 2 is that the FileMonitor is still trying to check the status of this
(non-existent) file so that LyX can refresh its display when the contents of the
file change (all those "lyx::sum() using mmap (lightning fast)" messages).

I'd guess that something somewhere is Asserting the existence of the file and
therefore bombing out.

[levon]

Angus, asserts do not cause SIGSEGV. And without a backtrace,
there is nothing we can do. So I think we should WORKSFORME this
bug in the absence of more data.

[laurent.charles@…]

As as I can reproduce the problem, as it seems I'm the one to face it, and as it
really bothers me, I could try to run some kind of debug session to provide
additional information.
Would some of you can send me (probably better in private) some information and
directions to run this bug hunting.

[levon]

Well, if you say that you've compiled with with --enable-debug (and also
with --disable-optimization) and you still get that wrong backtrace,
there's nothing more that can be done

[laurent.charles@…]

gdb debug session with backtrace

[flexx@…]

Am I the only one to think that anything below /tmp might not be the best prefix to
choose for -- even a temporary -- LyX installation?

Are you sure that the file in question is accessable by the user running lyx?

Just two thoughts...

[laurent.charles@…]

I agree that /tmp is not the best place. I just used it to reproduce the
problem. The problem occurs for me in three different locations in "normal"
filesystems (2 for Solaris 8, and 1 for Solaris 7).
And yes, the files are accessible, readable and executable by the user.

I'll check in my home dir to be sure. I'll be back.

[laurent.charles@…]

Back...

I tested on a regular filesystem (not /tmp) the new 1.3.1 version. The problem
is still there and reproductible every time. I tested with both xforms and qt
front-end.

Simple guess: I wonder if it might not be a side effect of development tools
used on my Solaris 8 box (gcc-2.95.3 & binutils 2.13.2)

[levon]

as per comment 8, comment 10

[michael.gerz@…]

Sorry, we have to set the status to VERIFIED (equivalent to CLOSED)