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 grexe)

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)

HaikuDepot-2100-debug-04-10-2023-17-46-30.report (33.4 KB ) - added by grexe 14 months ago.
crashlog_online (1.5 KB ) - added by grexe 14 months ago.
crash-log2.txt (2.9 KB ) - added by grexe 14 months ago.
HaikuDepot subsequently crashes after the first crash

Download all attachments as: .zip

Change History (8)

by grexe, 14 months ago

Attachment: crashlog_online added

comment:1 by grexe, 14 months ago

Description: modified (diff)

comment:2 by grexe, 14 months ago

Description: modified (diff)

by grexe, 14 months ago

Attachment: crash-log2.txt added

HaikuDepot subsequently crashes after the first crash

comment:3 by apl-haiku, 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 grexe, 14 months ago

Yes I was careful not to introduce any race conditions so I could exclude those.

comment:5 by apl-haiku, 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.

Note: See TracTickets for help on using tickets.