Opened 14 months ago
Last modified 14 months ago
#18620 new bug
HaikuDepot crashes when browsing packages
Reported by: | grexe | Owned by: | apl-haiku |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Applications/HaikuDepot | Version: | R1/Development |
Keywords: | crash | Cc: | |
Blocked By: | Blocking: | ||
Platform: | x86-64 |
Description (last modified by )
using latest nightly as of now, which is hrev-57309.
as followup to #18619 I also get crashes when being online, although later. Here (see log), I was just browsing the package list in Details tab, and highlighted an app (gmime). Out of nowhere, HaikuDepot crashed.
Update: now the cache seems to be corrupt, but HaikuDepot detects it is still up to date, tries to reuse it, and crashes. HaikuDepot should detect a corrupt cache and throw it away, or offer the option to clean the cache after a crash.
Attachments (3)
Change History (8)
by , 14 months ago
Attachment: | HaikuDepot-2100-debug-04-10-2023-17-46-30.report added |
---|
by , 14 months ago
Attachment: | crashlog_online added |
---|
comment:1 by , 14 months ago
Description: | modified (diff) |
---|
comment:2 by , 14 months ago
Description: | modified (diff) |
---|
by , 14 months ago
Attachment: | crash-log2.txt added |
---|
comment:3 by , 14 months ago
Hello; Are you able to confirm if you waited for it to complete the data loading process before viewing packages or were viewing packages while it was loading data in?
comment:4 by , 14 months ago
Yes I was careful not to introduce any race conditions so I could exclude those.
comment:5 by , 14 months ago
The application is taking a long time to load data into itself at the moment and I am hoping to be able to get a profiler or debugger on it soon. However I don't see crashing behaviour at the current time.
I have tried to scale the CPU capacity of the VM up and down and tried to use the application for 10-15mins and am unable to reproduce this problem. Can you please reproduce the problem on another machine to verify the issue is present there.
Can you please clarify how you have ascertained that the application has damaged its cached data and then crashed upon re-reading it. When the application does fail to load a cached file, in most cases it will log ...failed processing data
. In this situation it will execute the logic in AbstractServerProcess::MoveDamagedFileAside(..)
which will move the damaged file into another file with the suffix __damanged
. Do you see a file such as this in your ~/config/cache/HaikuDepot
directory?
Even if you do not then you can check the files in there manually. To check the icons tar-ball;
tar -tz ~/config/cache/HaikuDepot/pkgicon-all.tar > /dev/null && echo $?
Do you see any errors or does it print 0
on the screen?
To check the .json.gz
cache files you can first install the jq
tool with pkgman install jq
and then you can issue a command such as.
cat file.json.gz | gzip -d | jq . > /dev/null && echo $?
Do you see a 0
printed on the console or do you see some error messages? If it is zero then you likely have a sound compressed JSON file.
Let me know what you find.
HaikuDepot subsequently crashes after the first crash