Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#1656 closed bug (invalid)

the get_system_info_test.cpp fails

Reported by: kaoutsis Owned by: axeld
Priority: normal Milestone: R1
Component: - General Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

the get_system_info_test.cpp always fails on Haiku; on beos however passes successfully.

I will also attach the memory_monitor.cpp which shows clearly that the memory is freed, and the get_system_info succeeded on haiku (if the events are monitored from another team).

the problem may be:

  • thread can't get the updated system infos,

namely, get_sytem_info fails inside the thread that performs the changes to the resources. or

  • free() although has freed the memory, the

thread hasn't been notified for this event. or both?

Attachments (2)

get_system_info_test.cpp (2.2 KB) - added by kaoutsis 12 years ago.
the test app
memory_monitor.cpp (701 bytes) - added by kaoutsis 12 years ago.
a simple memory monitor

Download all attachments as: .zip

Change History (8)

Changed 12 years ago by kaoutsis

Attachment: get_system_info_test.cpp added

the test app

Changed 12 years ago by kaoutsis

Attachment: memory_monitor.cpp added

a simple memory monitor

comment:1 Changed 12 years ago by axeld

Resolution: invalid
Status: newclosed

Memory management works very differently on both systems, and that test just cannot work for Haiku. You could use create_area() instead, but even that could only work reliably if that's the only running app, and there are no driver running that might need memory...

comment:2 in reply to:  1 Changed 12 years ago by kaoutsis

Replying to axeld:

Memory management works very differently on both systems, and that test just cannot work for Haiku. You could use create_area() instead, but even that could only work reliably if that's the only running app, and there are no driver running that might need memory...

the get_system_info_test.cpp: allocates a chunk of 64 MB, then free() is called, and then the thread asks the system through get_system_info() to know how much free memory is there, which should be the number of pages before the allocation; is that invalid?

comment:3 Changed 12 years ago by axeld

Yes, as you never know how the allocator works. It might not immediately free the memory, but cache it in some way, or parts of it.

Also, any other system service might have needed memory in the mean time (including the possibility of paging in parts of your own executable), and that is totally unpredictable, since you're measuring the global amount of free pages.

comment:4 in reply to:  3 Changed 12 years ago by kaoutsis

Replying to axeld:

Yes, as you never know how the allocator works. It might not immediately free the memory, but cache it in some way, or parts of it.

Also, any other system service might have needed memory in the mean time (including the possibility of paging in parts of your own executable), and that is totally unpredictable, since you're measuring the global amount of free pages.

Ok, thanks! a) so the memory_monitor.cpp is invalid also? it seems to work. b) how can someone retrieve infos with the use of get_system_info in a safety manner?

comment:5 Changed 12 years ago by axeld

Whatever get_system_info() returns is a momentary report on resource usage. The only thing safe about this is that if you'd crash in that function (KDL), the results would accurately describe the current status quo. You also cannot measure how much memory a specific application is actually using vs. how much it has reserved (ie. cached).

Since memory_monitor.cpp does not make any assumptions about the values it prints out, it's of course okay. The number of free pages only count those pages that are actually not used by the system at all (ie. are either in the free or clear page queue). HTH :-)

comment:6 in reply to:  5 Changed 12 years ago by kaoutsis

Replying to axeld:

Whatever get_system_info() returns is a momentary report on resource usage. The only thing safe about this is that if you'd crash in that function (KDL), the results would accurately describe the current status quo. You also cannot measure how much memory a specific application is actually using vs. how much it has reserved (ie. cached).

Since memory_monitor.cpp does not make any assumptions about the values it prints out, it's of course okay. The number of free pages only count those pages that are actually not used by the system at all (ie. are either in the free or clear page queue). HTH :-)

yes, it's more clear now, thanks! the "sin" line is:

	if (tempInfo.used_pages == info.used_pages) {
		// Still the get_system_info shows the allocated pages.
Note: See TracTickets for help on using tickets.