Qt library crashes

[A]

Please reference https://bugs.kde.org/show_bug.cgi?id=329793 for traceback.

12.04.3 LTS
konversation:
  Installed: 1.4-1ubuntu2
  Candidate: 1.4-1ubuntu2
  Version table:
 *** 1.4-1ubuntu2 0
        500 http://us.archive.ubuntu.com/ubuntu/ precise/main i386 Packages
        100 /var/lib/dpkg/status
---
ApportVersion: 2.0.1-0ubuntu17.6
Architecture: i386
DistroRelease: Ubuntu 12.04
MarkForUpload: True
Package: konversation 1.4-1ubuntu2
PackageArchitecture: i386
ProcEnviron:
 LANGUAGE=
 TERM=xterm
 PATH=(custom, no user)
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 3.2.0-58.88-generic-pae 3.2.53
Tags: precise third-party-packages
Uname: Linux 3.2.0-58-generic-pae i686
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: lpadmin root scanner sudo

[Andy-90254 (andy-90254)]

Application: konversation (1.4)
KDE Platform Version: 4.12.0
Qt Version: 4.8.2
Operating System: Linux 3.2.0-58-generic-pae i686
Distribution: Ubuntu 12.04.3 LTS

-- Information about the crash:
- What I was doing when the application crashed:
Typing. Just typing. Nothing special. Just typing. I hope this backtrace is sufficient to figure it out because this is starting to happen on a regular basis.

-- Backtrace:
Application: Konversation (konversation), signal: Segmentation fault
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0xb76f8780 (LWP 8393))]

Thread 4 (Thread 0xb5a24b40 (LWP 8394)):
#0 0x006c8c64 in __pthread_mutex_unlock_usercnt () from /lib/i386-linux-gnu/libpthread.so.0
#1 0x02d62714 in pthread_mutex_unlock () from /lib/i386-linux-gnu/libc.so.6
#2 0x0127e430 in g_mutex_unlock () from /lib/i386-linux-gnu/libglib-2.0.so.0
#3 0x0123eb36 in g_main_context_check () from /lib/i386-linux-gnu/libglib-2.0.so.0
#4 0x0123f002 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#5 0x0123f1c1 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0
#6 0x028e9de7 in QEventDispatcherGlib::processEvents (this=0xb5100468, flags=...) at kernel/qeventdispatcher_glib.cpp:426
#7 0x028b56ad in QEventLoop::processEvents (this=0xb5a24200, flags=...) at kernel/qeventloop.cpp:149
#8 0x028b5949 in QEventLoop::exec (this=0xb5a24200, flags=...) at kernel/qeventloop.cpp:204
#9 0x0279ea1c in QThread::exec (this=0x926ca48) at thread/qthread.cpp:501
#10 0x02892cfd in QInotifyFileSystemWatcherEngine::run (this=0x926ca48) at io/qfilesystemwatcher_inotify.cpp:248
#11 0x027a1eb0 in QThreadPrivate::start (arg=0x926ca48) at thread/qthread_unix.cpp:307
#12 0x006c5d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#13 0x02d54bae in clone () from /lib/i386-linux-gnu/libc.so.6

Thread 3 (Thread 0xb45ffb40 (LWP 8396)):
#0 0x00419416 in __kernel_vsyscall ()
#1 0x02d4425b in read () from /lib/i386-linux-gnu/libc.so.6
#2 0x0127d6ce in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#3 0x0123eb92 in g_main_context_check () from /lib/i386-linux-gnu/libglib-2.0.so.0
#4 0x0123f002 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#5 0x0123f52b in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0
#6 0x014a44aa in ?? () from /usr/lib/i386-linux-gnu/libgio-2.0.so.0
#7 0x01262673 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#8 0x006c5d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#9 0x02d54bae in clone () from /lib/i386-linux-gnu/libc.so.6

Thread 2 (Thread 0xb4f15b40 (LWP 8410)):
#0 0x02d626e0 in pthread_mutex_unlock () from /lib/i386-linux-gnu/libc.so.6
#1 0x0127e430 in g_mutex_unlock () from /lib/i386-linux-gnu/libglib-2.0.so.0
#2 0x0123ec38 in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0
#3 0x0123f0e5 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#4 0x0123f1c1 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0
#5 0x028e9de7 in QEventDispatcherGlib::processEvents (this=0xb46088b8, flags=...) at kernel/qeventdispatcher_glib.cpp:426
#6 0x028b56ad in QEventLoop::processEvents (this=0xb4f...

[Christoph-maxiom (christoph-maxiom)]

The crash happens deep in the Qt library. I suggest to update Qt to version 4.8.5. While you are using newest KDE 4.12, you are still using a quite old Qt 4.8.2.

[Andy-90254 (andy-90254)]

Please provide details as to how to update Qt in ubuntu 12.04.3 I run apt-get update daily and install all updates. I don't know why it wouldn't have come down if it was there...

Thank you

[Christoph-maxiom (christoph-maxiom)]

Please ask in Ubuntu forums how to update to Qt 4.8.5.

[Andy-90254 (andy-90254)]

I'm told to compile the source. Quite strange to me that I should need to go through these gyrations. Working on compiling it now.

[A (publicface)]

apport information

[Andy-90254 (andy-90254)]

Basic XLib functionality test failed!
 You might need to modify the include and library search paths by editing
 QMAKE_INCDIR_X11 and QMAKE_LIBDIR_X11 in /usr/local/src/qt-everywhere-opensource-src-4.8.5/mkspecs/linux-g++.

This is where I get off the boat. For a user to have to be a developer to use a simple IRC client is ridiculous. Bug is NOT resolved.

[Hein (sho)]

Here are the facts we know:

- The crash information in your bug report tells us the crash occurs inside the Qt library used by Konversation.

- Your version of the Qt library is almost two years old.

- There are many Konversation users, but you're the only one reporting this crash.

This leads us to conclude that the bug is unlikely to be in Konversation, and unlikely to be something Konversation can affect.

It also seems likely the bug would go away for you if you used newer software, since otherwise we'd be seeing more crash reports like this.

For any Konversation developer to be able to do anything about this bug, we'd have to be able to reproduce it, but we can't reproduce it with the available information, nor do we have such old Qt versions ourselves to test with.

Hence there's nothing we can do, and while I understand you're frustrated the app is crashing for you, there's no immediate use for this ticket to stay open.

[Andy-90254 (andy-90254)]

What I object to is the message you're sending. The problem has not been resolved in any sense of the word. "Deflected" would be closer to the truth. "Won't fix" is also reasonable nomenclature for this situation. "Resolved" implies fixed. While that may be what you consider it as far as the application code proper is concerned, it is not an accurate reflection of the status of the problem from my point of view.

There are facts, and then there is customer service. If you wouldn't say it to your grandmother, then you shouldn't say it to anyone else, especially not a customer. And yes, anyone using the software is a customer aka user.

The fact that nobody else is willing to go out of their way to take the time and energy I put forth, along with the knowledge required to make it all the way to this point speaks not to the solidity of the software, but of the tenaciousness of the user. I spent over 8 hours today alone chasing this down trying to get it resolved. The vast majority of users - especially those of a non-technical background - wouldn't put up with, nor spend their time on this kind of nonsense. First the application would get dumped for something else, and failing satisfaction with that - then abandonment for a different OS entirely where the support system doesn't force the user to be a tech guru.

I've been using Linux for years and I've been as big an evangelist as anyone. But quite frankly I'm embarrassed to recommend it to anyone without a strong technical background because of exactly this kind of issue and associated attitude.

I do appreciate that the problem is not strictly within the konversation code proper, but instead within a component used by konversation, but that doesn't mean there's nothing you can do. To say "nor do we have such old Qt versions ourselves to test with" is patently false, because I didn't go out of my way to downgrade to this version. This is what came with the system and is readily available to anyone that wants it as I installed it fresh not one month ago - the one labeled "LTS" - Long Term Support as you well know. Do I expect you to go out of your way to test with an older version when something newer and more exciting is available? No, not really and I can appreciate that there is a newer library component which may or may not fix the issue.

While upgrading to newer software (where "software" could mean a wide variety of things from just the library to the entire OS) might be the proper solution from your point of view - and I'm not necessarily objecting to that as the solution (upgrading the library, not the OS), what I do object to is the general "it's not my problem you're on your own" attitude. Which leads me back to - is that what you'd tell your grandmother?

The proper way to have handled this would have been to take ownership of the problem - whether it's truly your area of responsibility or not - and guide me as far as you're able. That means this response "The crash happens deep in the Qt library. I suggest to update Qt to version 4.8.5. While you are using newest KDE 4.12, you are still using a quite old Qt 4.8.2." was a very good start and I applaud Cristoph for it...

[Hein (sho)]

> There are facts, and then there is customer service.

This website is not a customer service venue, it's a developer tool. The goal is to do well by our users, but to do so we have to operate with efficiency, and keeping the bug database in a condition useful to developers helps with that.

Yes, we could kiss your arse and hand you chocolates and all the other trappings of traditional customer relations, but the relation we prefer is to treat you as our equal in the participative endeavour that open source development is (the fruits of which you also got for free, by the way). As our equal we hope you would mind the same broader concerns we need to mind, such as spending our resources wisely. With that in mind I did not deflect anything, instead I offered reason. I'm sorry you felt not respected, but I hope you can see the respect that is in transparency of that kind.

> To say "nor do we have such old Qt versions ourselves to test with" is patently false, because I didn't go out of my way to downgrade to this version.

None of the Konversation developers uses Kubuntu/Ubuntu. Konversation nor KDE are affiliated with that distro. "LTS" is a promise made by your system vendor; you should inquire why they don't support you by supplying bugfixes that already exist.

[Christoph-maxiom (christoph-maxiom)]

> "Resolved" implies fixed.

"Resolved" means, there is no further work to be done by KDE developers in this bug tracker.

This is either because the bug is fixed by KDE developers, or has to be fixed elsewhere. If you want your distribution to supply newer Qt versions, please report this to the bug tracker of your distribution.

[Harald Sitter (apachelogger)]

(In reply to comment #8)
> you should inquire why they don't support you by supplying bugfixes
> that already exist.

Where's the bugfix?

[Hein (sho)]

> Where's the bugfix?

I was referring to the dozens (if not hundreds) of bug fixes listed in the Qt 4.8.3 - 4.8.5 maintenance release changelogs.

[Harald Sitter (apachelogger)]

12.04 contains Qt 4.8.1, the report indicates 4.8.2, so unfortunately this setup is not support because it is not using a supported Qt package.

[Harald Sitter (apachelogger)]

The reason in that case is: Last someone (not me) checked, KDE did not claim to support Qt versions released after the release of a given KDE SC version (in fact I seem to recall an incident where mixing a newer Qt maintenance release with an older plasma-desktop release actually went south). Or more generally put, because changing the entire version of a toolkit library has too great potential to go wrong only selective fix backporting is done. So, since Kubuntu 12.04 contains KDE SC 4.8 it uses Qt 4.8.1.

On that note, the report is definitely not from an actually supported Kubuntu 12.04 because it indicates Qt 4.8.2... handling this in the new downstream report though.

[Hein (sho)]

Thanks Harald.

[Andy-90254 (andy-90254)]

(In reply to comment #8)
> > There are facts, and then there is customer service.
>
> This website is not a customer service venue, it's a developer tool. The

Really. So then you're NOT interested in bug reports from users. Good to know.

> goal is to do well by our users, but to do so we have to operate with
> efficiency, and keeping the bug database in a condition useful to developers
> helps with that.

And how are my previous suggestions at odds with "keeping the bug database in a condition useful to developers"? While "resolved" may satisfy your needs, there's no reason an additional flag couldn't be added. Something like "Dependency Broken" perhaps. I'm sure you can think of something appropriate that would satisfy everyone's needs.

> Yes, we could kiss your arse and hand you chocolates and all the other
> trappings of traditional customer relations, but the relation we prefer is
> to treat you as our equal in the participative endeavour that open source

I don't need kisses or candy, but it's a symbiotic relationship. I'm not a Konversation developer, I'm a Konversation user. Without users there is little reason to have the product. That means we have an equal interest, it does not necessarily mean we have equal skills or knowledge. The developers are intimate with the product and it's components, the users are not - nor should that be a requirement of usage. You are strongly implying I should have the same skills & knowledge as a developer of your product, if I want to use your product. If that's true, then this isn't the right product for me as I want to use the product, not troubleshoot it.

> [...] Kubuntu/Ubuntu. Konversation nor
> KDE are affiliated with that distro.

Well that I find to be a fascinating statement, which puts an interesting perspective on the situation. It means K/ubuntu bares responsibility for making KDE and Konversation work on Ubuntu, which I suppose makes sense. But it does require the user to be knowledgeable about the situation. The average user doesn't care who is responsible, s/he simply wants to have a working system. If the system doesn't work, the user generally goes elsewhere if at all possible. Users tend to gravitate towards the path of least pain.

"LTS" is a promise made by your system
> vendor; you should inquire why they don't support you by supplying bugfixes
> that already exist.

And you are absolutely right that bugfixes should be supplied by the vendor. Unfortunately the problem is one of complexity. Once again, you are requiring the user to be intimately familiar with a highly complex system that is comprised of an overwhelming number of similarly complex pieces. The user cannot be expected to understand the details of the relationship between subsystems, and so it falls to the developer to notify and interact with the system vendor, else it is likely that the problem will not get fixed.

Here's what will typically happen instead
Newbie: "So I'm looking for an IRC client for Kubuntu. Any recommendations?"
Voice of Experience: "Yes. Whatever you do, avoid Konversation because it keeps crashing and the developer doesn't care."

I would hope that's not the res...

[Christoph-maxiom (christoph-maxiom)]

> While "resolved" may satisfy your needs, there's no reason an additional flag couldn't be added.

There is an additional flag, the bug status is "resolved UPSTREAM", which means the bug is in a component not in control of KDE developers, this time the Qt library developed by the Qt project. Before going to point you to the bug tracker of the Qt project, I wanted to make sure the bug is still reproducible with Qt 4.8.5.

For more information, please read http://www.kde.org/code-of-conduct/

[Andy-90254 (andy-90254)]

(In reply to comment #9)
If you want your distribution to supply newer Qt versions,
> please report this to the bug tracker of your distribution.

This gets to the heart of the problem. You should be the one to take responsibility for reporting it. It took me an entire day and part of my night to figure out 1) that I needed to report it, 2) where and how to report it. With an additional 5 minutes of your time you would have saved me 10 hours of mine.

Eike stated "As our equal we hope you would mind the same broader concerns we need to mind, such as spending our resources wisely."

Yet here we have an example where this is blatantly not true. I'm not being treated as an equal, because you've decided that 5 minutes of your time is more valuable than 10 hours of my time. You saved 5 minutes of your time and squandered 10 hours of mine. How is that equal? Or fair?

[Hein (sho)]

> So then you're NOT interested in bug reports from users.

On the contrary, I'm very interested in bug reports from users. But bug reports are contributions to a participative development process, not a customer service inquiry. You're informing us you've noticed what may be a bug; we're going to use this information as we see fit to make our software better.

> While "resolved" may satisfy your needs, there's no reason an additional flag couldn't be added. Something like "Dependency Broken" perhaps.

That's exactly what "RESOLVED UPSTREAM" means. As a developer I agree that Bugzilla could be improved for our needs, by the way, and by extension the needs of our users, but this ticket isn't the place to discuss Bugzilla improvements.

> You are strongly implying I should have the same skills & knowledge as a developer of your product, if I want to use your product.

No, I think you misread that. I don't think you should need to have the same skills and knowledge as I do (in fact Konversation stands to benefit more if you bring different skills and knowledge to the table). I do expect you to be aware of the mode in which Konversation is developed (by volunteers, non-commercially, in the open) and have more than your own needs on your agenda, e.g. the need for us to triage reports and decide where to spend finite resources to help the most users. If you can't do that, I recommend switching to a product that offers a different kind of relation with you indeed.

I've spent 8 years and hundreds of hours on improvements to Konversation, most of them due to suggestions or inquiries by users. Some of my fellow developers have been around even longer. I have a very clean conscience about my contributions to the bottom line here.

> The average user doesn't care who is responsible, s/he simply wants to have a working system.

That might accurately reflect the status-quo, but isn't a desirable state of things, partly because it's not sustainable. We don't have the resources to hide the complexity of the development process from users or succeed without your help. If we did, we'd also fail to recruit new developers to replace those who move on. We also feel that doing so does users a disservice in the long run, since you don't have the full picture to make useful decisions.

> The user cannot be expected to understand the details of the relationship between subsystems, and so it falls to the developer to notify and interact with the system vendor, else it is likely that the problem will not get fixed.

This is true, and you'll be relieved to hear that this communication happens all the time. The Konversation team (as well as many other people in KDE) maintain strong relations with many distros, and many bugfixes that distros end up pushing to users also in lower-level components are the result of us asking them to ship them. We talk literally every day, and improving this communication (e.g. by linking bug trackers to maintain upstream/downstream references for the same problem) is an active topic of conversation.

However, in this case it's not reasonable from a resource POV to do this until the bug has been confirmed to exist with a more recent v...

[Hein (sho)]

> Yet here we have an example where this is blatantly not true. I'm not being treated as an equal, because you've decided that 5 minutes of your time is more valuable than 10 hours of my time. You saved 5 minutes of your time and squandered 10 hours of mine. How is that equal? Or fair?

This is simply not an accurate reflection of how it went down -- Christoph did refer you to the next proper venue to inquire about the availability of a newer version of Qt for your system to test with: Ubuntu forums. The people there are more effective at helping with Ubuntu-specific problems than we are, i.e. you're likely overestimating our knowledge there. For example, I have honestly no idea if there is a newer Qt available for your Ubuntu version anywhere. I'd have to ask someone else or ask a search engine, too.

Christoph in particular triages tons and tons and tons of user reports almost every day, and it's not reasonable to expect him to write long step-by-step tutorials in every response that take into account all the variables you might encounter and that he would need to research himself. His time is better spent doing exactly what he did here, and exactly what you request: He used the knowledge and time he does have available to interpret and classify your problem, and tell you where to go with it. There's no reason to assume he wasn't acting in good faith and to the best of what his circumstances would allow.

[Hein (sho)]

I'm sorry for the mail spam, everyone, but an attempt to summarize this before I close out the day, in the hopes we can all move on: Your point that developers should have empathy for their users is well taken. I do understand the frustration you experienced, and I regret that this became somewhat adversarial. I'm also genuinely grateful that you did take the time and effort to report a bug at all, as said earlier I consider that a contribution to Konversation, and all contributions deserve respect.

Your contribution isn't moot, either. The problem on your end isn't resolved immediately, but you know now how it fits into the larger picture (-> no similar crash reports, so updating software looks like a good bet), and we won't forget either. If we get a similar report again, we have more to go on, and more to tell.

However, empathy has to go both ways; it's important for users to have empathy for the situation of developers, too, in particular with this mode of software development. Customer service is an ill-suited concept here since we are not, in fact, servants. Both kinds of empathy have to exist to grease the wheels of this process.