https://bugs.kde.org/show_bug.cgi?id=350365
--- Comment #65 from Thiago Macieira ---
Will provide that when it happens again.
--
You are receiving this mail because:
You are the assignee for the bug.
thiago added a comment.
This new backtrace *is* a stuck application. Please report the issue to Mesa
(dri/i965). Cc me, I can walk three paces in the office to the Mesa devs and
help them figure out what's happening.
Mesa debug symbols would be helpful.
Anyway, as a workaround for t
thiago added a comment.
I repeat: there's no indication in the backtrace that it is stuck. What's
your evidence that it is? You wrote an application that shows nothing and never
exits. Now it showed nothing and didn't exit. That's not stuck, that's the
expected behaviour.
REPOSITORY
R871
thiago added a comment.
This last backtrace does not show anything stuck. Thread 1 was actively
running, in fact (it's inside of malloc).
Also note your testcase has no window, since the widget is destroyed before
app.exec().
REPOSITORY
R871 DrKonqi
REVISION DETAIL
https://phabrica
thiago added a comment.
The patch is innocuous. I don't see *how* it can solve anything, though,
because I don;'t know what DrKonqu::cleanup does.
The commit message is nonsense. This problem has nothing to do with D-Bus.
That's a red herring, because the QDBusConnection thread only exi
t 6.
>
> Please therefore ensure your application handles redirects
> appropriately (the form of the code will depend on the version of Qt
> in use) if you decide to use QNAM.
You do that by setting the attribute FollowRedirectsAttribute in your
QNetworkRequests.
--
Thiago Macieira
#x27;s enough time to make sure it works.
PS: I've been running KDE trunk with Qt 4.7 since the TP and this is the best
so far. I have only one minor annoyance.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
Em Terça-feira 02 Março 2010, às 15:49:18, Thiago Macieira escreveu:
> I'm actually raising the bar here.
>
> I'm turning on QT_FATAL_WARNINGS by default in Qt debug builds (starting
> with Qt 4.7).
After suggesting this to Qt developers, the overwhelming reaction was
E/.xsession-errors isn't enough (mine was over 4GB the other
day).
If the warning is a problem in Qt or cannot be fixed without Qt help, says so!
I don't care who's to blame, just as long as those warnings stop showing up.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (A
Em Terça-feira 10 Novembro 2009, às 15:02:15, ext Petri Damstén escreveu:
> On Tuesday 10 November 2009 15:42:18 Kenneth Christiansen wrote:
> > Hi again.
> >
> > I talked to Thiago Macieira and he told me that QUrl in 4.6 is more
> > strict than in 4.5, but there
Em Terça-feira 10 Novembro 2009, às 14:42:18, ext Kenneth Christiansen
escreveu:
> Hi again.
>
> I talked to Thiago Macieira and he told me that QUrl in 4.6 is more
> strict than in 4.5, but there isn't any behaviour change.
>
> Can you please give me examples that stopp
lace
to determine what's good for KDE.
3) Qt-only applications shouldn't be doing requires(KDE4)
4) The decision is a compile-time one, not run-time. That is, non-KDE code
that may get loaded into a KDE application is allowed to use QHttp. But KDE
code loaded into a Qt-only applicat
thus break.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
From 7e23865b55b25d895eeb026d41e044057d214709 Mon Sep 17 00:00:00 2001
From: Thiago Macieira <[EMAIL PROTECTED]>
Da
13 matches
Mail list logo