Crash under Snow Leopard

[mahrain]

While running Mac OS X Snow Leopard (10a432 10.6.0) LyX crashed, however, the application seemed to be running still and I could still save my files and exit normally.

My setup is a:

MacBook? (5,1) Core 2 Duo
Mac OS X Snow Leopard 10.6.0 (10a432)
MacTex? 2008

Fresh install, no upgrades to the software anywhere.

A LyX file with bibtex bibliography.

I was editing an itemized list at the time of the problem.

See the attachment for the console log (vfr).

[sanda]

do you have some recipy to reproduce? maybe something to do with autosave as i see in backtrace.

[mahrain]

Just leaving the application open for a while will cause this, it needn't be more than a few minutes.

Turning off Autosave didn't help.

Surprisingly, the app stays up and is still working - it seems - properly, after this crash happens.

[vfr]

Console log

[vfr]

This bug has been confirmed on the users' list (also with Snow Leopard). In this report, turning off autosave did help as we expected from the backtrace. Also, the fact that LyX remains 'active' after the crash indicates that the error occurs within the autosave thread.

see:
http://www.mail-archive.com/lyx-users@lists.lyx.org/msg76148.html

[mahrain]

I had a Mac developer look at this and he told me:

"[This] is a MacOSX bug: disallowing a process to fork violates the POSIX standard. It is unfortunate that Apple intentionally breaks the standard here, and we will implement a workaround for this shortcoming."

"OS X tells you that you are doing dangerous things. It does not forbid you to fork() in general, it tells you to fork() and exec() when it cannot guarantee you that the libs you are using are safe from async-signal-safe.
Can you guarantee your code can be forked even in a signal handler at any time? This is what POSIX demands."

"Lyx is trying to fork() without exec(), this is allowed by POSIX standards, however, if OS X cannot guarantee that the libraries in use are 'async-signal-safe' this is not allowed and it crashes the thread."

So, since I'm just the translator in this case, maybe this will help someone who understands this matter to workaround for Snow'?

[wbray]

The problem persists with or without autosave turned on. With it off, it seems to crash less often. I am attaching a console report of the last crash.
I must say, this seems to be a false crash. When the crash window appears, you can simply click OK; the Lyx window remains open and the document can be edited, saved, etc.

The attached report again indicates what has been stated above. Apparently Snow Leopard is reacting to fork() without exec().

[mahrain]

Did a quick grep on the latest Lyx sources. This is what popped up:

int AutoSaveBuffer::generateChild()
{
    // tmp_ret will be located (usually) in /tmp
    // will that be a problem?
    // Note that this calls ForkedCalls::fork(), so it's
    // ok cross-platform.
    pid_t const pid = fork();
    // If you want to debug the autosave
    // you should set pid to -1, and comment out the fork.
    if (pid != 0 && pid != -1)
        return pid;

    // pid = -1 signifies that lyx was unable
    // to fork. But we will do the save
    // anyway.
    bool failed = false;
    FileName const tmp_ret = FileName::tempName("lyxauto");
    if (!tmp_ret.empty()) {
        buffer_.writeFile(tmp_ret);
        // assume successful write of tmp_ret
        if (!tmp_ret.moveTo(fname_))
            failed = true;
    } else
        failed = true;

This is the only place where a call to fork() can be found in the Lyx source. That, and the name of this function, strongly suggests that this is where the autosaving takes place.

I'm fairly sure that this can be rewritten to use a thread instead of a process, in order to work around the OS X bug.

[Luc484]

pth could be used myabe?

[vfr]

The difficulty will probably be that we will have to copy the document before starting the new thread, because it must be possible for the user to continue editing his document.

[lasgouttes]

Ticket #6238 has been marked as duplicate.

[spitz]

Jean-Marc disabled fork() on Mac OSX in trunk:
http://www.lyx.org/trac/changeset/31696

I understand it's just a workaround, so not yet fixedintrunk.

[lasgouttes]

I have to had that this workaround will not find a place in branch until some Mac user volunteers to test it (under 10.5 and 10.6 ideally). Note that this patch makes LyX slower for everybody when saving. I have another patch to speedup somewhat file saving.

If somebody tell me how to determine OS version at runtime, I can make the patch affect only 10.6.

[ghrossman]

If somebody tell me how to determine OS version at runtime,
I can make the patch affect only 10.6

system_profiler SPSoftwareDataType | grep "System Version: " | awk '{print $6}'

[mattias]

Dynamic detection of snowleopard

[mattias]

Replying to lasgouttes:

I have to had that this workaround will not find a place in branch until some Mac user volunteers to test it (under 10.5 and 10.6 ideally). Note that this patch makes LyX slower for everybody when saving. I have another patch to speedup somewhat file saving.

If somebody tell me how to determine OS version at runtime, I can make the patch affect only 10.6.

Hope the function I added is OK, if you want me to fix anything in it, just note that down here and I'll get on it.

[SeanBurke]

Replying to mattias:

Replying to lasgouttes:

I have to had that this workaround will not find a place in branch until some Mac user volunteers to test it (under 10.5 and 10.6 ideally). Note that this patch makes LyX slower for everybody when saving. I have another patch to speedup somewhat file saving.

If somebody tell me how to determine OS version at runtime, I can make the patch affect only 10.6.

Hope the function I added is OK, if you want me to fix anything in it, just note that down here and I'll get on it.

The above C code doesn't detect snow leopard properly. Line 14 should read:

if (mid == 6) {

not

if (maj == 10) {

Best,

Sean

[SeanBurke]

Replying to lasgouttes:

I have to had that this workaround will not find a place in branch until some Mac user volunteers to test it (under 10.5 and 10.6 ideally). Note that this patch makes LyX slower for everybody when saving. I have another patch to speedup somewhat file saving.

I'm willing to test it out under 10.5 & 10.6. Do you have a build available or should I check the source out from version control?

Sean

[mattias]

Replying to SeanBurke:

Replying to mattias:

Replying to lasgouttes:

I have to had that this workaround will not find a place in branch until some Mac user volunteers to test it (under 10.5 and 10.6 ideally). Note that this patch makes LyX slower for everybody when saving. I have another patch to speedup somewhat file saving.

If somebody tell me how to determine OS version at runtime, I can make the patch affect only 10.6.

Hope the function I added is OK, if you want me to fix anything in it, just note that down here and I'll get on it.

The above C code doesn't detect snow leopard properly. Line 14 should read:

Yes, it does, the check is for the kernel version. I have also tested it under snow leopard and leopard. The correspondence between kernel version and OS X version is:

Darwin 10.0.0 = Mac OS 10.6
Darwin 9.0.0 = Mac OS 10.5
Darwin 8.0.0 = Mac OS 10.4
Darwin 7.0.0 = Mac OS 10.3
Darwin 6.0.* = Mac OS 10.2
Darwin 1.4.* = Mac OS 10.1
Darwin 1.3.* = Mac OS 10.0

Thus, for snow leopard the correct is maj = 10.

[SeanBurke]

Thus, for snow leopard the correct is maj = 10.

I stand corrected - sorry about the confusion. I just checked out the 1_6_X branch and got a build failure:

g++ -DHAVE_CONFIG_H -I. -I../.. -I./.. -I../../boost -DQT_NO_STL -DQT_NO_KEYWORDS -DQT_SHARED -I/usr/local/Trolltech/Qt-4.4.3/include -I/usr/local/Trolltech/Qt-4.4.3/include/QtCore -Wextra -Wall -g -Os -MT docstring.lo -MD -MP -MF .deps/docstring.Tpo -c docstring.cpp -o docstring.o

docstring.cpp:20:17: error: QFile: No such file or directory
docstring.cpp: In function ‘const lyx::docstring lyx::from_local8bit(const std::string&)’:
...

A little Makefile archeology in the src/support directory shows that something seems to be handing bad values for QT4_CORE_CFLAGS and QT4_CORE_INCLUDES. My QTDIR is at /Developer/qt. The rest of the distribution found it ok, so I'm guessing it's a configure error. In either case, a soft link is an ugly but effective solution.

For the lazy and suspiciously trusting, I have posted a build of the 1_6_5 branch based on this morning's sources.
You can get it at: http://www.pride.hofstra.edu/~SBURKE12/lyx_1.6.5.svn.dmg

Best,

Sean

[SeanBurke]

For the lazy and suspiciously trusting, I have posted a build of the 1_6_5 branch based on this morning's sources.
You can get it at: http://www.pride.hofstra.edu/~SBURKE12/lyx_1.6.5.svn.dmg

That link should be:
http://www.pride.hofstra.edu/~SBURKE12/lyx_1.6.5.svn.dmg.zip

Sorry - I really need to increase my morning caffeine dosage.

[lasgouttes]

Thanks for the code allowing to detect version at runtime. Since nobody complained (yet) that autosave is now too slow, I'll stay with the crude-but-safe solution. We'll see whether we need the clever version later.

I have a new patch against branch that should work correctly. Please test under 10.5 and 10.6 for autosave, spellcheck and instant preview (they use fork()).

[lasgouttes]

Fix snow leopard crash with autosave

[vfr]

Don't worry about the slow autosave. All Windows users have to live with it and nobody ever complained AFAIK.

[spitz]

fixedinbranch:
http://www.lyx.org/trac/changeset/32055

(and also in LyX 1.6.4.2)

What about trunk?

[lasgouttes]

Fixed in trunk now at r32067.

Closing, since 1.6.4.2 is released.