Georg Baum wrote:
> Am Mittwoch, 14. Juni 2006 19:34 schrieb Peter Kümmel:
>> Under Windows it crahes here when leaving Lyx:
>>
>> src/lyx_main.C
>> #else
>> if (err_sig == SIGSEGV || !getEnv("LYXDEBUG").empty())
>> #endif
>> lyx::support::abort();
>> exit(0); <-
Am Mittwoch, 14. Juni 2006 19:34 schrieb Peter Kümmel:
> Under Windows it crahes here when leaving Lyx:
>
> src/lyx_main.C
> #else
> if (err_sig == SIGSEGV || !getEnv("LYXDEBUG").empty())
> #endif
> lyx::support::abort();
> exit(0); < line 442
Sorry,
On Wed, Jun 14, 2006 at 06:54:31PM +0200, Georg Baum wrote:
> Andre Poenitz wrote:
>
> [qApp crash]
>
> > this happens within its own event loop.
> >
> > No good.
> >
> > [That's btw pretty similar to terminating the event loop by throwing an
> > exception through it - does this sound familiar
Georg Baum wrote:
> I'd like to know:
>
> - Does this work on windows?
> - What about the comment about QApplication::exit above? Is it still
> correct?
Under Windows it crahes here when leaving Lyx:
src/lyx_main.C
#else
if (err_sig == SIGSEGV || !getEnv("LYXDEBUG").empty())
#endif
Andre Poenitz wrote:
[qApp crash]
> this happens within its own event loop.
>
> No good.
>
> [That's btw pretty similar to terminating the event loop by throwing an
> exception through it - does this sound familiar?]
>
> As I said: Try to terminate the event loop by a less drastic means.
> Sc
On Sun, Jun 11, 2006 at 11:16:22PM +0200, Peter Kümmel wrote:
> Andre Poenitz wrote:
> > On Thu, Jun 08, 2006 at 02:08:52PM +0200, Georg Baum wrote:
> >> What I don't understand is: Why does it work for other windows users?
> >
> > Single processor vs multiple processor is known to make a differen
On Thu, Jun 08, 2006 at 03:23:17PM +0200, Georg Baum wrote:
> I don't know what exactly happens. Here is a backtrace:
>
> #0 0x406d3426 in QObject::QObject () from /usr/lib/libQtCore.so.4
> #1 0x404beb56 in QInputContext::QInputContext ()
> from /usr/lib/libQtGui.so.4
> #2 0x404bff93 in QXIMInp
On Thu, Jun 08, 2006 at 10:56:37AM +0200, Peter Kümmel wrote:
> > QObject::killTimer: timers cannot be stopped from another thread
>
>
> the infinit loop happens after the ::exit(status); call.
Please try to replace ::exit() with some less intrusive termination
mechanism.
Andre'
On Fri, Jun 09, 2006 at 11:22:32AM +0200, Georg Baum wrote:
> This really smells like either a bug in our code or in qt.
Our shutdown is broken.
Andre'
On Thu, Jun 08, 2006 at 06:52:29PM +0200, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Peter Kümmel <[EMAIL PROTECTED]> writes:
> | > > toStdString is not available here (see QT_NO_STL).
> | > "fromqstr" is what I was looking for! :)
> |
> | Incidentally, Peter, y
On Thu, Jun 08, 2006 at 11:59:50AM +0200, Peter Kümmel wrote:
> This fixes it, then also the static QTranslator makes no problem,
> and it would be hard to forbid all static Qt objects.
You can make qApp or the main window parent of such objects and
get them destructed at predictable times.
Andre
On Thu, Jun 08, 2006 at 02:08:52PM +0200, Georg Baum wrote:
> What I don't understand is: Why does it work for other windows users?
Single processor vs multiple processor is known to make a difference.
Not sure that's the issue here, though.
Andre'
Jean-Marc Lasgouttes wrote:
>> "Georg" == Georg Baum
>> <[EMAIL PROTECTED]>
>> writes:
>
> Georg> Jean-Marc, did you make up your mind regarding 1.4?
>
> I just did some testing, and I think you can commit it.
Done.
Georg
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Jean-Marc, did you make up your mind regarding 1.4?
I just did some testing, and I think you can commit it.
JMarc
Abdelrazak Younes wrote:
> Georg Baum wrote:
>> The QApplication is now constructed as an automatic object as advised in
>> the qt doumentation (not from main(), but that should not matter, since
>> nothing qt related happens after lyx_gui::exec is left).
>
> Are we really sure of that? I know th
Georg Baum wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Indeed I solved the problem by adding a static there:
For trunk that would be:
#ifdef Q_WS_WIN
static LQApplicationapp(argc, argv);
#else
LQApplication app(argc, argv);
#endif
This works fine her
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>> Abdelrazak Younes wrote:
>>> Indeed I solved the problem by adding a static there:
>>
>>> For trunk that would be:
>>>
>>> #ifdef Q_WS_WIN
>>> static LQApplicationapp(argc, argv);
>>> #else
>>> LQApplication app(argc, argv);
>>> #endif
>>
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>> Remind be agins why we use QT_NO_STL?
Angus> If I remember rightly, John was worried that we were switching
Angus> from QString to std::string and back again without thinking
Angus
Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
> Remind be agins why we use QT_NO_STL?
If I remember rightly, John was worried that we were switching from QString to
std::string and back again without thinking about it. (!QT_NO_STL provides
implicit conversion from one to the other.) The frontend
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Indeed I solved the problem by adding a static there:
For trunk that would be:
#ifdef Q_WS_WIN
static LQApplicationapp(argc, argv);
#else
LQApplication app(argc, argv);
#endif
This works fine here with msvc.
But when I call lyx from the
Abdelrazak Younes wrote:
> Indeed I solved the problem by adding a static there:
> For trunk that would be:
>
> #ifdef Q_WS_WIN
> static LQApplicationapp(argc, argv);
> #else
> LQApplication app(argc, argv);
> #endif
This works fine here with msvc.
But when I call lyx from the command l
Angus Leeming <[EMAIL PROTECTED]> writes:
| Peter Kümmel <[EMAIL PROTECTED]> writes:
| > > toStdString is not available here (see QT_NO_STL).
| > "fromqstr" is what I was looking for! :)
|
| Incidentally, Peter, you should add QT_NO_STL to the options passed by Scons
to
| the compiler when comp
Peter Kümmel wrote:
Georg Baum wrote:
Here you are basically reintroducing the static app variable, and therefore
the crash on exit on linux. A scoped_ptr is supposed to be equivalent to a
normal object variable concerning construction and destruction, so if that
is needed i think the old soluti
Angus Leeming wrote:
> Peter Kümmel <[EMAIL PROTECTED]> writes:
>>> toStdString is not available here (see QT_NO_STL).
>> "fromqstr" is what I was looking for! :)
>
> Incidentally, Peter, you should add QT_NO_STL to the options passed by Scons
> to
> the compiler when compiling the Qt frontend. W
Peter Kümmel wrote:
> Maybe they've used mingw, I use msvc.
So unless you find out what happens here I see no other possibility than
adding an #ifdef for msvc.
> Seems the destruction order is implemented different by those
> two compilers. Why crashes it under Linux? Also because of
> Qt object
Peter Kümmel <[EMAIL PROTECTED]> writes:
> > toStdString is not available here (see QT_NO_STL).
> "fromqstr" is what I was looking for! :)
Incidentally, Peter, you should add QT_NO_STL to the options passed by Scons to
the compiler when compiling the Qt frontend. We should aim for the various
buil
Georg Baum wrote:
> Here you are basically reintroducing the static app variable, and therefore
> the crash on exit on linux. A scoped_ptr is supposed to be equivalent to a
> normal object variable concerning construction and destruction, so if that
> is needed i think the old solution of Abdel is
Peter Kümmel wrote:
> This fixes it, then also the static QTranslator makes no problem,
> and it would be hard to forbid all static Qt objects.
Only those that interact with QApplication could be problematic.
> Could I at least check in the translator stuff, because
> at the current state lyx wi
Peter Kümmel wrote:
> Georg Baum wrote:
>>> - QTranslator qt_trans(0);
>>> - if (qt_trans.load(QString("qt_") + QTextCodec::locale(),
>>> - qInstallPathTranslations())) {
>>> + static QTranslator qt_trans;
>> Why do you make this static? Does it work if you
Georg Baum wrote:
>> - QTranslator qt_trans(0);
>> - if (qt_trans.load(QString("qt_") + QTextCodec::locale(),
>> - qInstallPathTranslations())) {
>> + static QTranslator qt_trans;
>
> Why do you make this static? Does it work if you remove the static
> qua
Peter Kümmel wrote:
> Georg Baum wrote:
>> Does it work if you always use exit instead of lyx_gui::exit in lyx_exit
>> (lyx_main.C)?
>
> No, still the same.
Then I guess that we have another desctrion order problem.
> Index: frontends/qt4/lyx_gui.C
>
Georg Baum wrote:
> Does it work if you always use exit instead of lyx_gui::exit in lyx_exit
> (lyx_main.C)?
No, still the same.
$ svn diff
Index: lyx_main.C
===
--- lyx_main.C (revision 14038)
+++ lyx_main.C (working copy)
@@ -
Peter Kümmel wrote:
>> But since yesterday it never ends when exiting lyx:
>>
>> QObject::killTimer: timers cannot be stopped from another thread
>
>
> the infinit loop happens after the ::exit(status); call.
Does it work if you always use exit instead of lyx_gui::exit in lyx_exit
(lyx_main.C)
Peter Kümmel wrote:
> [EMAIL PROTECTED] wrote:
>> Author: baum
>> Date: Thu Jun 8 08:53:11 2006
>> New Revision: 14038
>>
>> Log:
>> app -> qApp, forgot this with the last patch
>>
>> Modified:
>> lyx-devel/trunk/src/frontends/qt4/lyx_gui.C
>
> But since yesterday it never ends when exiting l
[EMAIL PROTECTED] wrote:
> Author: baum
> Date: Thu Jun 8 08:53:11 2006
> New Revision: 14038
>
> Log:
> app -> qApp, forgot this with the last patch
>
> Modified:
> lyx-devel/trunk/src/frontends/qt4/lyx_gui.C
But since yesterday it never ends when exiting lyx:
QObject::killTimer: timers c
35 matches
Mail list logo
