On Oct 3, 2008, at 2:14 PM, Abdelrazak Younes wrote:
On 03/10/2008 11:59, address@hidden wrote:
On Oct 3, 2008, at 10:14 AM, Abdelrazak Younes wrote:
On 02/10/2008 14:53, address@hidden wrote:
I've done some testing on current cvs texmacs and the situation is
the
following:
- linking with qt4.4.3 release version leads to crash (gdb session
attached below).
- linking with qt4.4.3 debug version works fine
- linking with qt4.3.5 debug or release works fine
So current hypothesis is that it is a problem with the release
version
of 4.4.3. Moreover I just commited some patches which should allow
correct visualization of characters under Linux (at least for me
works
on Red Hat Enterprise with Linux 2.6.9-78.0.1.ELsmp)
The problem is that a statusbar update is asked while in a paint
event (see relevant backtrace snippet below). Older version of Qt
did not complained but Qt4.4 changed the way child widgets are
painted. We had the same crash in LyX when Qt4.4 was released. The
solution was simply to remove the statusbar update call in the
paint event. As a general rule, don't do any painting (even onto a
pixmap) inside a paint event.
Hope this helps,
Abdel.
#58 0x00bae4b5 in QWidget::repaint (this=0x93aec10,
address@hidden) at painting/qbackingstore.cpp:1140
#59 0x00a342c5 in QWidget::repaint (this=0x93aec10) at
kernel/qwidget.cpp:8933
#60 0x00df44b6 in QStatusBar::reformat (this=0x93aec10) at
widgets/qstatusbar.cpp:530
#61 0x00df4d6a in QStatusBar::event (this=0x93aec10, e=0x9726e48) at
Thanks Abdelrazak. But I cannot see where I violate the rule you are
suggesting. status bar updates are issued outside paint events (as
far as I can see with gdb) and I also tried to remove them without
success.
Weird... But I am pretty sure that the status bar is guilty here.
I agree something strange is going on I will indagate further.
Moreover it is really strange that the program works with the debug
version and not with the release one, without giving warning.
The event in question might be delayed in debug mode so that this bug
is not triggered.
This could be true.
Could you point me to some relevant documentation about this issue
(trolltech docs or mailing list posts...).
There is our bug report which contains a number of link to other bug
reports and discussion:
http://bugzilla.lyx.org/show_bug.cgi?id=4568
I really do not undertand but it is clear that the current status of
the port is very instable under Linux (at least with Q4.4/release).
Alvaro is experiencing another type of crash but I think that his is
related to some problems with 64 bits.
What is the build system ogf TeXMacs? If CMake, scons or QMake, I can
try to compile it under Windows...
uses plain configure/make, it should work under mingw but I'm not sure.