Opened 7 years ago

Closed 4 years ago

#8309 closed bug (invalid)

Tracker crash

Reported by: Premislaus Owned by: axeld
Priority: normal Milestone: R1
Component: Applications/Tracker Version: R1/Development
Keywords: tracker, crash, lag, virtual memory Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

I used the computer as usual. I listened music, compiled small programs in Free Pascal compiler, documented bugs for Cipri in DocumentViewer, etc. Several times consumption reached 900 MB RAM( DocumentViewer) and system strongly slowed( lag). The full CPU usage was kernel team, especially the service releated with low resources( forgot the name). Three times hang tracker, but without turning on the debugger. Icons disappeared and was only deskbar, so I clicked restart the tracker. Finally started the debugger.

And yet installed theora and vorbis to check my previously reported bug.

When I do restart the computer, I am very surprised. Haiku always turned off 5 seconds, this time it lasted a few minutes. The longest it took for unmounting the partition( as was usually mounted two NTFS).

I turned off virtual memory and I have 1024 MB of RAM. I am writing about this because, in syslog is writing about virtual memory.

Haiku hrev43690 gcc2.

Attachments (4)

tracker_crash (6.2 KB) - added by Premislaus 7 years ago.
syslog (229.5 KB) - added by Premislaus 7 years ago.
syslog.old (512.1 KB) - added by Premislaus 7 years ago.
RAM_usage5.png (137.5 KB) - added by Premislaus 7 years ago.
One of the screenshots that I sent Cipri. Then I'll try to do more accurate.

Download all attachments as: .zip

Change History (11)

Changed 7 years ago by Premislaus

Attachment: tracker_crash added

Changed 7 years ago by Premislaus

Attachment: syslog added

Changed 7 years ago by Premislaus

Attachment: syslog.old added

comment:1 Changed 7 years ago by anevilyak

Unfortunately, it's a bit difficult to say much here without knowing who was using all that memory. The tracker crashes are a side effect of you simply running out of RAM, and the real question is why. This unfortunately can't really be determined from the information you've posted, but if this is repeatable it'd be helpful to know which teams are using how much (according to e.g. ProcessController).

comment:2 in reply to:  1 Changed 7 years ago by Premislaus

Replying to anevilyak:

Unfortunately, it's a bit difficult to say much here without knowing who was using all that memory. The tracker crashes are a side effect of you simply running out of RAM, and the real question is why. This unfortunately can't really be determined from the information you've posted, but if this is repeatable it'd be helpful to know which teams are using how much (according to e.g. ProcessController).

DocumentViewer consumes so much RAM. It has a bug in the form of scrolling of the document, then memory usage grows. A few days ago, I reported this bug for Cipri. Then it was such memory usage, but nothing happened. Only yesterday I checked many PDF files into a new version of the program, and checked any error.

I'll try to do screenshot.

It is strange to me, because earlier Haiku did not allow the total memory consumption. Not allowed to open another large file.

I was around 100 MB of free memory. But Haiku ceased to be very responsive, and then slowed.

Changed 7 years ago by Premislaus

Attachment: RAM_usage5.png added

One of the screenshots that I sent Cipri. Then I'll try to do more accurate.

comment:3 Changed 7 years ago by cipri

so, yes, the memory leak i will solve. I tried your pdf file and at least one page of it, is broken, that's the reason for the memory leak (because just now i started to introduce error handling code). Anyway thanks for the... broken pdf file, it use it in future for testing the viewer, so that it doesnt behave anymore bad in case of an error.

So i guess, that ticket can be closed als invalid?

comment:4 in reply to:  3 Changed 7 years ago by Premislaus

Replying to cipri:

so, yes, the memory leak i will solve. I tried your pdf file and at least one page of it, is broken, that's the reason for the memory leak (because just now i started to introduce error handling code). Anyway thanks for the... broken pdf file, it use it in future for testing the viewer, so that it doesnt behave anymore bad in case of an error.

So i guess, that ticket can be closed als invalid?

But Haiku should not crash. But it should display the information that the lack of RAM and should not be suspended, only to close applications. I had 124 MB free RAM.

comment:5 Changed 7 years ago by khallebal

i've been seeing these memory leaks for a while now,i don't think they are specific to cipri's app,i got memory leaks while i was using bezilla browser,a Qt based browser,web+ see ticket #8271,but i have no clue what's causing all these memory leaks,there is also this ticket that was closed as invalid #8184,wich i'm sure is also related. a wilde guess,some code in the Deskbar is causing this,or... the app_server?

comment:6 in reply to:  5 Changed 7 years ago by cipri

Replying to khallebal:

i've been seeing these memory leaks for a while now

Yes, but in that case, it's really my fault, i know exactly where in that case the memory is leaking. I was at the beginning too lazy, to handle to error cases, because i wanted to see it once working.

Memory leaks are indeed a problem, but perhaps we can improve using more often smart pointers that c++11 offer us now.

I guess since in that cases, we can not identify a system component leaking memory, we should perhaps close the ticket as invalid.

comment:7 Changed 4 years ago by waddlesplash

Resolution: invalid
Status: newclosed

I guess since in that cases, we can not identify a system component leaking memory, we should perhaps close the ticket as invalid.

Agreed. Please open a new ticket if you find a specific serious memory leak somewhere.

Note: See TracTickets for help on using tickets.