Opened 13 years ago
Closed 10 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: | ||
| 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)
Change History (11)
by , 13 years ago
| Attachment: | tracker_crash added |
|---|
by , 13 years ago
by , 13 years ago
| Attachment: | syslog.old added |
|---|
follow-up: 2 comment:1 by , 13 years ago
comment:2 by , 13 years ago
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.
by , 13 years ago
| Attachment: | RAM_usage5.png added |
|---|
One of the screenshots that I sent Cipri. Then I'll try to do more accurate.
follow-up: 4 comment:3 by , 13 years ago
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 by , 13 years ago
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.
follow-up: 6 comment:5 by , 13 years ago
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 by , 13 years ago
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 by , 10 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
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.
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).