segfault when repeatedly sorting
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Trojitá |
Unknown
|
Medium
|
||
| trojita (Ubuntu) |
Medium
|
Unassigned |
Bug Description
STEPS TO REPRODUCE
1. Click on a folder
2. Click a column header to sort by that column
3. Repeat #2 several times (can be a different header)
EXPECTED RESULTS
Every click on the column header should result in sorting, with multiple clicks on the same header alternating between ascending and descending.
ACTUAL RESULTS
Assuming there are more than a couple messages and the column header is clicked more than a couple times, the application segfaults.
AFFECTED VERSIONS
trojita 0.7-0ubuntu2 (also upstream git master 76151f1a9226b27
NOTES
Using the menu to change the sorting does not produce the same result, but it may be that it's impossible to change the sorting as quickly.
It seems that size of messages rather than just number of messages is important to reproduce this problems. Certainly more messages will promote the problem but bigger messages will have a more substantial effect.
The window size also has an effect. The smaller the window, the more likely the problem will occur.
marneu (marneu) wrote : | #1 |
description: | updated |
marneu (marneu) wrote : | #3 |
Good point. I've just tried it again, and sorting works fine in my smaller imap folders. The main inbox has 78 messages.
marneu (marneu) wrote : | #4 |
The size of the messages ranges from 2KB to 300KB, with the vast majority between 4KB and 10KB.
other points of interest:
- 99% of all mails in my inbox are gpg-encrypted (though it doesn't matter whether Trojita is able to decrypt them or not).
- I'm running it in a VirtualBox VM with 3D acceleration disabled.
Walter Lapchynski (wxl) wrote : | #5 |
I actually got this to fail in as little as about 10 messages. It's also that way in the latest git master, so it looks like it's an unsolved issue. Pushing upstream.
tags: | added: lubuntu |
summary: |
- Application quits when clicking on a column header + Application quits when repeatedly sorting |
description: | updated |
Changed in trojita (Ubuntu): | |
status: | Incomplete → Confirmed |
importance: | Undecided → Medium |
|
#6 |
STEPS TO REPRODUCE
1. Click on a folder
2. Click a column header to sort by that column
3. Repeat #2 several times (can be a different header)
EXPECTED RESULTS
Every click on the column header should result in sorting, with multiple clicks on the same header alternating between ascending and descending.
ACTUAL RESULTS
Assuming there are more than a couple messages and the column header is clicked more than a couple times, the application quits.
AFFECTED VERSIONS
trojita 0.7-0ubuntu2 (also upstream git master 76151f1a9226b27
NOTES
Using the menu to change the sorting does not produce the same result, but it may be that it's impossible to change the sorting as quickly.
DOWNSTREAM BUG
https:/
EXPECTED RESULT
SOFTWARE VERSIONS
(available in About System)
KDE Plasma Version:
KDE Frameworks Version:
Qt Version:
ADDITIONAL INFORMATION
description: | updated |
summary: |
- Application quits when repeatedly sorting + segfault when repeatedly sorting |
description: | updated |
Changed in trojita (Ubuntu): | |
status: | Confirmed → Triaged |
Changed in trojita: | |
importance: | Unknown → Medium |
status: | Unknown → New |
|
#7 |
I was able to get a backtrace after a long series of random clicking. This is with a random and pretty old snapshot of Qt.
Thread 1 "trojita" received signal SIGSEGV, Segmentation fault.
0x00007ffff2625fa9 in QSortFilterProx
430 /var/tmp/
(gdb) bt
#0 0x00007ffff2625fa9 in QSortFilterProx
#1 0x00007ffff2625fe1 in QSortFilterProx
#2 0x00007ffff2624ee5 in QSortFilterProx
#3 0x00007ffff35a4211 in QModelIndex::flags (this=0x7ffffff
#4 QTreeViewPrivat
#5 QTreeView:
#6 0x00007ffff35af1da in QTreeView:
#7 0x00007ffff353e42f in QAbstractItemVi
#8 0x00007ffff267106b in QMetaObject:
#9 0x00007ffff2671677 in QMetaObject:
at /var/tmp/
#10 0x00007ffff33de36e in QAbstractSlider
#11 0x00007ffff33de9d4 in QAbstractSlider
#12 0x00007ffff26711af in QtPrivate:
Changed in trojita: | |
status: | New → Unknown |
Rolf Leggewie (r0lf) wrote : | #8 |
I was unable to reproduce this with a self-compiled trojita 0.7-0ubuntu2 on bionic. Is this still an issue?
Changed in trojita (Ubuntu): | |
assignee: | nobody → Rolf Leggewie (r0lf) |
status: | Triaged → Incomplete |
Rolf Leggewie (r0lf) wrote : | #9 |
I intend to close this ticket soon if no confirmation of this still being a problem comes forward.
Walter Lapchynski (wxl) wrote : | #10 |
So with 10 emails, I can easily reproduce this in dingo with 0.7-0ubuntu2. With less emails, it doesn't work.
Changed in trojita (Ubuntu): | |
status: | Incomplete → Confirmed |
Dan Simmons (kc2bez) wrote : | #11 |
I was also able to reproduce this in cosmic with 0.7-0ubuntu2. For me, the segfault happened when there were 15 messages or more.
Dan Simmons (kc2bez) wrote : | #12 |
I neglected to mention in my previous comment that I was testing on a Dell Inspiron 7720 laptop with an Intel i5-3210 processor and 8 Gb of RAM.
Walter Lapchynski (wxl) wrote : | #13 |
My last comment was on live in a VM. I redid it in an installed VM with 2G memory allocated and needed to up it to 20 messages before I could get it to die. Somehow it seems there there's some sort of proportional relationship between the number (or size as many of mine were small) of messages and the amount of memory. Similar results with latest git (b94f4307).
description: | updated |
Changed in trojita (Ubuntu): | |
status: | Confirmed → Triaged |
Changed in trojita (Ubuntu): | |
assignee: | Rolf Leggewie (r0lf) → nobody |
Unfortunately, I can't reproduce this. I do have a fairly empty inbox, though. How many messages and what size are you dealing with?