userbrowse core dump #25
Step to reproduce:
 + 10743 abort (core dumped) python nicotine.py
Bisected to 12424d4 if i'm not wrong.
Can anyone confirm this ?
The text was updated successfully, but these errors were encountered:
With one file I can't reproduce it since the down arrow will have nothing to go through.
One way I'm able to easily reproduce it on ubuntu 16.04 / fedora 24 is :
It happens for me after less than 3-4s, it does even goes to the "files" subdir it crashes before.
Thx for the tests. I've just spawned a debian VM and I agree it works under debian stable up-to-date.
IMHO it's not a bug in GTK but more likely a bug in the uglytree.py custom tree model.
From what i gather uglytree.py was introduce to fix http://nicotine-plus.org/ticket/480 because loading a big directory structure was slow.
So by curiosity I've checked out the version of userbrowse.py before the uglytree.py introduction and as expected it was slow but at least not crashing :).
After a rewrite and doing some optimization like:
I managed to take it down to 5s.
This is still a little bit slower than the uglytree.py model but I think I might be able to push the load in a thread to avoid blocking the UI for 5s (need some code refactoring).
After that i've adapted some functions in userbrowse.py (search and download related) because the 'shares' data structure had changed over the years.
One bonus in this version: changing the encoding via the dropdown list change the fileview encoding AND the treeview encoding (when uglytree was introduced they seems to have forgotten that).
Anyway when I'm done with this branch I might ask for your help for testing it out :)
I'm not trying to hand wave anything I assure you.
I've tried to debug the uglytree.py module more than once now and I think I'm on something.
You have to first expand everything down in 'test1' subdir and then try to expand 'test2' surdir.
Too play around and see want would happen I added yet another subdir test1111 in the first branch.
Now it crashes too, but I even have a traceback with an out of range index;
On Debian & Windows: no traceback at all and still no crash...
For the root cause we can exclude PyGTK (2.24.0) which is the same on every OS.
So either GTK 2.24.30 is borked or uglytree.py was throwing crap at GTK this entire time but GTK was happily dismissing it.
I will look at it futher and test if I can fix it in uglytree.py.
OK great, just found it curious as to my knowledge this wasn't an issue for many years so good to know the actual cause and it looks like you are looking into that. I checked the userbrowse rework branch you have so far and didn't notice any issues. Not sad that uglytree dies if browse speed is maintained, and it looks fast to me.
Yes it's strange. The GTK2 changelog from 2.24.25 to 2.24.30 seems not that big but it's causing problems only for this specific part. Other parts of n+ using a standard model (searches, userlist, etc..) aren't affected from what I can see.
What would be nice is testing every point release between 2.24.25 and .30 to find out when things begins to go south, but since they're not packaged under fedora/ubuntu it would imply building GTK from source and testing manually which would take time. I'm a little bit short of it since the end of holidays :)
Things I still need todo on the branch based on the standard model used before uglytree:
I will try to finish most of it before the end of the next week-end.
I've just finished up the conversion of the upload part.
I will do most the the testing part Wednesday evening.
So far I've tested these combinations without any visible regressions for browse/download/upload.
This branch N+ Linux => This branch N+ Linux with virtual shares
This branch N+ Linux => N+ 1.2.16 Linux old share format
Last few tests I need to do before merging to this branch on master:
This branch N+ Linux => Official SLSK client Linux