Development

hrev49040.

While watching a video from sshfs I can see how userlandfs_server is leaking memory using ProcessController. This is what I noticed in debug report.

11461	0x18038000	0x601d8000	   1181312	rw-        	full          	heap

1181312 is in KiB

fixed:

This problem does not trigger a panic anymore. However the underlying issue may still be there, and you will see it in the syslog (warnings with the same message). If you still manage to boot and use the system it is probably not a problem for you then.

fixed:

#6188 was fixed, maybe this helps in your case.

Moho 2.5 dont render animations.
Maybe a software problem... maybe not!

Will add screenshoots...
And the bug report...

Please check..

checkhash
If this is set, Bash checks that a command found in the hash table exists before trying to execute it. If a hashed command no longer exists, a normal path search is performed.

This could avoid some issues when uninstalling non-packaged or home/config version of a package, in that case bash sometimes fails to see that the command is now available in /system.

This was introduced with USB3 and is an alternative to the traditional and quirky USB Mass Storage. It allows better performance as SCSI commands can be queued and executed out of order by the device.

​http://en.wikipedia.org/wiki/USB_Attached_SCSI

Support is available in Windows 8, Mac OS X 10.8, and Linux (not sure which version). UAS can be implemented over USB 2.0 as well.

On Dec 24, 2014 7:20 PM, Michael Mounteney gate03@xxxxxxxxxxxxxxx wrote: I tried to build but ran into problems. I think it was designed for gcc2 only. Use instead. -Augustin ...

I tried to build but ran into problems. I think it was designed for gcc2 only. Michael. ...

260 MB

260 MB

262 MB

262 MB

Booted up hrev49036 x86_gcc2 and debugger activated as soon as the Desktop appeared. Could not save reports, and killing the debugger would activate another. Tried to reboot and was greeted with a string of debugger calls...print server, media server etc.

This is only an optical change. This is only an optical change.

Because of the virtual hooks a BLayout must never be destroyed while it still has layout items. If these items are only removed from the layout in its destructor, the subclass version of hooks like ItemRemoved() are not called anymore. This lead to leaks because many BLayout subclasses use the ItemRemoved() hook to clean up associated data (as is suggested explicitly in the BLayout documentation). In the same line of thought, a BLayoutItem must never be deleted when it is still attached to a layout, as it similarly has virtual hooks like DetachedFromLayout() that can not be called at this point anymore. The destructors of BLayout and BLayoutItem now have debugger calls in case these conditions are not met which should help to avoid accidentally introducing such hard to debug issues. To ensure the correct destruction order the sequence is now: * Destroy the child views first. This cleans up their layout items while the layout tree is still intact. * Unset the view layout before removing layout items so it can properly detach from the layout instead of just deleting it. Because of the virtual hooks a BLayout must never be destroyed while it still has layout items. If these items are only removed from the layout in its destructor, the subclass version of hooks like ItemRemoved() are not called anymore. This lead to leaks because many BLayout subclasses use the ItemRemoved() hook to clean up associated data (as is suggested explicitly in the BLayout documentation). In the same line of thought, a BLayoutItem must never be deleted when it is still attached to a layout, as it similarly has virtual hooks like DetachedFromLayout() that can not be called at this point anymore. The destructors of BLayout and BLayoutItem now have debugger calls in case these conditions are not met which should help to avoid accidentally introducing such hard to debug issues. To ensure the correct destruction order the sequence is now: * Destroy the child views first. This cleans up their layout items while the layout tree is still intact. * Unset the view layout before removing layout items so it can properly detach from the layout instead of just deleting it.

DebuggerInterface,Architecture{X86,X8664}: - Add hook function for retrieving a feature flag mask for the target CPU, and corresponding implementation in Architecture-specific classes. ArchitectureX86: - Read CPU features on init, and use them to restrict the exposed set of registers such that the MMX and SSE registers will only be visible if the target CPU actually supports the respective instructions. DebuggerInterface,Architecture{X86,X8664}: - Add hook function for retrieving a feature flag mask for the target CPU, and corresponding implementation in Architecture-specific classes. ArchitectureX86: - Read CPU features on init, and use them to restrict the exposed set of registers such that the MMX and SSE registers will only be visible if the target CPU actually supports the respective instructions.

* This exclude some possible cheating cases. It impose to have only a buffer_id per thread, so instances will not be duplicated if not needed. * This exclude some possible cheating cases. It impose to have only a buffer_id per thread, so instances will not be duplicated if not needed.

It works analoguous to BView::RemoveSelf(), i.e. it removes itself from the parent (layout in this case) and returns whether or not it had and was successfully removed from said parent. It works analoguous to BView::RemoveSelf(), i.e. it removes itself from the parent (layout in this case) and returns whether or not it had and was successfully removed from said parent.