[HaikuDepot] crash in PackageInfo::Title(PackageInfo)

[Iosend]

I running search after start - on search in HaikuDepot

[vidrep]

hrev52047 x86_gcc2h

Debugger report attached

[apl-haiku]

I am trying this now and don't see a problem on hrev52080 (x86_gcc2); is there a specific keyword that causes the problem to occur?

[vidrep]

It seems that most of theses crashes are occurring on a first time search after a fresh install of Haiku, which is something I do quite often. Updates are not so much affected.

[vidrep]

Would it help for me to do another fresh install, then start HaikuDepot from Terminal, to see if it will crash again? Please refer to blocker ticket: https://dev.haiku-os.org/ticket/14184

[apl-haiku]

Hello; If you have time to try a fresh install to see if it still happens for you, it would be appreciated; otherwise I will come back to it when I can.

[vidrep]

I was able to reproduce the problem on consecutive fresh installs. It appears that HaikuDepot is not fully populating on first launch. It will only do so when repositories are refreshed. If you enter a search term before the refresh, it will crash. Line 46 is where the error occurs. I have attached a terminal log of HaikuDepot first launch, and repository refresh.

[waddlesplash]

I attempted to reproduce this on x86_gcc2 by deleting the following folders:

/system/cache/tmp
~/config/cache/HaikuDepot
~/config/settings/HaikuDepot

... and then after launching HaikuDepot I got output nearly identical to vidrep's log, but trying to search at any point in that did not result in a crash. I also disabled internet access after deleting the folders, so that HaikuDepot could not refresh, and it still didn't crash.

@vidrep, could you see if you can find a way to reproduce without a fresh install? If not, I'll try to debug and then fix it that way.

[vidrep]

I have attached a pair of terminal logs and screenshots to illustrate the issue.

[apl-haiku]

I have followed these guessed steps to reproduce the problem;

• pulled my development branch to master and built a new ISO
• installed the ISO into a VirtualBox environment
• Run HaikuDepot desktop application
• Unchecked "Show only featured packages"
• Type some search terms into the search box a few times

I unfortunately don't seem to see this problem mentioned arising.

| ... It will only do so when repositories are refreshed ...

^{Can you clarify here. Do you mean when the operating system pulls a fresh hpkr from the remote site or do you mean HaikuDepot retrieves fresh package meta-data from the server?}

One thing I see in your log that I do not see in mine;

...
SSL error:00000002:lib(0):func(0):system lib
[ServerIconExportUpdateProcess] did complete streaming data [1744896 bytes]
delete any existing stored data
will unpack to [/boot/home/config/cache/HaikuDepot/__allicons]
unable to unpack item data to; [/boot/home/config/cache/HaikuDepot/__allicons/hicn/jnpad_j/64.png]
did unpack 1415 tar items
error occurred unpacking tar items; Value too large for defined type
did complete fetching icons
...

The tar-ball downloaded from the server is *actually* around 3206365 bytes long - around 2x the length of what your client is downloading. I see this error in the following supplied logs from yourself;

• HaikuDepot_first_launch.txt​
• HaikuDepot_refresh_terminal.txt​

I wonder if this might somehow have something to do with it?

[vidrep]

See edited comment: 8

[vidrep]

For additional info: https://dev.haiku-os.org/ticket/13940#comment:16

[vidrep]

Had another crash today using hrev52175 x86_gcc2h. Entering a search term before the icons have loaded appears to have been the cause. This time it was NOT on a fresh install, but one that has been updated several times. Debugger report attached.

[diver]

Still here in hrev53142.

[apl-haiku]

I spent some more time on it, but am still unable to reproduce this error locally. Is somebody other than vidrep able to try to reproduce this error following the procedures on this ticket?

In the error trace I see the following calls in the stack trace;

SearchTermsFilter::AcceptsPackage(SearchTermsFilter) + 0x7f
Model::MatchesFilter(Model) + 0x5a
Model::CreatePackageList(Model) + 0xee
MainWindow::_AdoptModel() + 0x25
MainWindow::MessageReceived(BMessage*) + 0x8de
BLooper::DispatchMessage(BMessage*, BHandler*) + 0x59
...

Without being able to check, it appears that;

void
MainWindow::_AdoptModel()
{
  fVisiblePackages = fModel.CreatePackageList();
...

...should be locking the fModel across the CreatePackageList() method call. I can't see the problem to see if this fixes it, but I think that this lock should be there anyway so I'll add it via PR and we can see.

[vidrep]

hrev53152 x86_64

I could not reproduce the crash on a fresh install.

[waddlesplash]

Fix merged in hrev53157.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone