continue with B_OK. This also fixes CID 1122 where in such a case an
uninitialized token would be returned.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27695 a95241bf-73f2-0310-859d-f6bbb57e9c96
used in the switch statement. Change that to continue early when a filed size of
<= 0 is encountered.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27488 a95241bf-73f2-0310-859d-f6bbb57e9c96
this should fix LinkSender usage like as in Stroke/ FillPolygon in BView
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27226 a95241bf-73f2-0310-859d-f6bbb57e9c96
this makes printing of large images work, fixes task #1067
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27214 a95241bf-73f2-0310-859d-f6bbb57e9c96
was pretty broken. It would store the address of the buffer in the message
instead of the actual data. Funnily, since it was completely stack based before,
it would have stored the address plus the actual data (minus 4 bytes) as that
did reside directly after the address on the stack and the original buffer
length was still used. This corrupted the data, but still "worked" for MDR
because it has fault tolerance, loosing only part of its flattened StringList.
This broke however when switching to a heap allocated buffer for large sizes,
as then the heap address plus some random heap data was added to the message
instead of the actual buffer. Sure interesting that nobody noticed that before...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26984 a95241bf-73f2-0310-859d-f6bbb57e9c96
passed to the function against NULL.
* Made BMessage::AddFlat() use an optionally heap allocated buffer versus always
a stack allocated one.
* Small simplification in BMessage::AddMessage(), we can simply compare the
buffer with the stack based buffer to know whether we need to free() it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26943 a95241bf-73f2-0310-859d-f6bbb57e9c96
inefficient. And while it did check if the handler was not NULL, it would have
resulted in an endless loop if it was. I think we can safely assume we have no
NULL BHandlers in that list though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26870 a95241bf-73f2-0310-859d-f6bbb57e9c96
which does
message->GetInfo("field", &type, &count);
while (message->FindBlah("field", --count, &...) == B_OK)
...;
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26695 a95241bf-73f2-0310-859d-f6bbb57e9c96
loppers fHandlers list, otherwise we might end up with a dangeling pointer.
This should fix the crashes seen in Cortex and Icon-O-Matic on app close.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26383 a95241bf-73f2-0310-859d-f6bbb57e9c96
message correctly, it is a bit strange why the message should not follow
protocol.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25499 a95241bf-73f2-0310-859d-f6bbb57e9c96
are NULL pointers anyway, we just adjust argc.
* Made argv processing more safe, it will now check if the allocation of the
argv array succeeded in the first place.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25496 a95241bf-73f2-0310-859d-f6bbb57e9c96
properly credit James Woodcock, who debugged this problem and whom I forgot
to mention in my previous commit. Sorry!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25495 a95241bf-73f2-0310-859d-f6bbb57e9c96
_ArgvReceived(), the array elements still need to be set to NULL otherwise
the function will free() random pointers at the end.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25494 a95241bf-73f2-0310-859d-f6bbb57e9c96
to contain headers shared by kernel and userland (mainly libroot).
* Moved quite a few private kernel headers to the new location. Split
several kernel headers into a shared part and one that is still kernel
private. Adjusted all affected Jamfiles and source in the standard x86
build accordingly. The build for other architectures and for test code
may be broken.
* Quite a bit of userland code still includes private kernel headers.
Mostly those are <util/*> headers. The ones that aren't strictly
kernel-only should be moved to some other place (maybe
headers/private/shared/util).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25486 a95241bf-73f2-0310-859d-f6bbb57e9c96
defined/undefined to numeric values (0 for undefined). This allows for
trace levels.
* Set SYSCALL_TRACING_IGNORE_KTRACE_OUTPUT default to 1, since this is
what one usually wants.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25213 a95241bf-73f2-0310-859d-f6bbb57e9c96
this fixes bug #1762 (Installer: trying to close it via alt+q shows warning twice)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25084 a95241bf-73f2-0310-859d-f6bbb57e9c96
_init_interface_kit_() in there.
* Moved private get_mode_parameter() into the BPrivate namespace.
* Renamed interface_misc.h to InterfacePrivate.h.
* Minor other cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24869 a95241bf-73f2-0310-859d-f6bbb57e9c96
finally created a solution to avoid that: Header files that contain
configuration settings (and nothing else) go to build/config_headers.
To change settings, create a directory build/user_config_headers (which
is ignored by svn), copy the respective header there and modify it at
your leisure. Currently only tracing_config.h has been moved to the new
location, but more files will follow eventually. It is also recommended
to move optional macro definitions in Jamfile (as for BFS) to a config
header instead; the build system will then automatically rebuild on
changes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24611 a95241bf-73f2-0310-859d-f6bbb57e9c96
Note: I have cleared the original MessageQueue.cpp file from the inline documentation. When the storage kit comes up, we need to rediscuss the documentation policy.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24522 a95241bf-73f2-0310-859d-f6bbb57e9c96
locked.
* Removed some long and useless comments.
* Other minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24445 a95241bf-73f2-0310-859d-f6bbb57e9c96
the new sematic of transfer_area so a message area is transfered into the right
teams' address space and it does not need to be cloned there anymore. Passing
by area is only used for messages bigger than a certain size (currently
hardcoded to 40KB) which should be somehow bound to the max port message size.
This makes passing large messages (i.e. > the port limit) possible, so for
example copy&paste of long text, image data, etc. should now work.
Got rid of the fClonedArea member as it is not necessary with the new design,
renamed shared_area to message_area in the private message_header, avoid
an unnecessary allocation of the header for the copy constructors, check
allocations in a few more places and some minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24321 a95241bf-73f2-0310-859d-f6bbb57e9c96
Tracked down the root cause of the issue worked around in r24228.
The behavior that was occurring in this case was as follows:
Vision created a BInvoker off the heap, containing a BMessage likewise
off the heap. It then called BAlert::Go with this invoker. When any of
the buttons in the BAlert were pushed, _SendMessage would enqueue the
message into the target looper (in this case, Vision's window) and wake
it up with write_port_etc. However, in some cases this would result in
a reschedule such that Vision's looper executed before _SendMessage() was
able to complete all its processing. Upon receiving this message, Vision
destroyed the BInvoker in question, which in turn deleted its owned
BMessage -- which was the message that was still in the middle of _SendMessage()!.
Consequently it would crash a few lines later when it hit IsSourceWaiting() and
tried to check flags off its header off the already destroyed this. To fix this,
we now do the AddMessage/write_port_etc last before returning. Also removed the
sanity checks added in r24228 so we don't mask other problems of similar nature.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24297 a95241bf-73f2-0310-859d-f6bbb57e9c96
set up with a null replyTo, sometimes BMessage would crash
calling IsSourceWaiting() after delivering the message. This appeared
to be because fHeader was NULL, but I'm not entirely certain if this
is actually supposed to be possible, so this may be masking a different
bug. This was observable using the multiline paste spam BAlert in
Vision, which would sometimes but not always crash in Haiku after hitting
any of the buttons to dismiss it, though consistently when calling IsSourceWaiting()
from the private BMessage::_SendMessage().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24228 a95241bf-73f2-0310-859d-f6bbb57e9c96
- no need to initialize the buffer on stack
- no need to initialize "buffer" to NULL
- renamed "buf" to stackBuffer
- enlarged buffer on stack to 16384 bytes (we have a minimum of 192 kB of
stack per thread, anyway).
- check the actual size of the stack buffer against the message's flattened
size instead of the one of its pointer.
- check if the allocation of the helper buffer failed, and return B_NO_MEMORY
in this case.
* Moved static helper functions to the top of the file.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24204 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Allocate the buffer to flatten the message on the heap, if it's size is bigger then a given
buffer on the stack. It seem's to exceed the stack size (this might count for AddFlat() too).
Note: With this change one is able to copy the text into the clipboard (1mb), but it
is still impossible to paste it somewhere, as in BClipboard::_DownloadFromSystem()
SendMessage() fails transferring the data back in the reply msg because of the port size limit...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24196 a95241bf-73f2-0310-859d-f6bbb57e9c96
BMessenger::SendMessage(), which could lead to deadlocks (as in bug
#1745).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23865 a95241bf-73f2-0310-859d-f6bbb57e9c96
destination of the message and it's "what" field are stored. It might be
nice to also get some info about its fields -- maybe as an additional
option.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23810 a95241bf-73f2-0310-859d-f6bbb57e9c96
already using.
* We don't have to try posting _QUIT_ more than once, as it cannot block; the
looper is local, so direct message passing is used in this case.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23690 a95241bf-73f2-0310-859d-f6bbb57e9c96
field was not initialized properly, and the reply target was taken from the
wrong header in this case.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22925 a95241bf-73f2-0310-859d-f6bbb57e9c96
have been a problem though, since the iterated container is a list.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22535 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Since the app_server launched the input_server, it would also get notified
when the latter died via a signal - but LinkReceiver could return B_INTERRUPTED
in that case (it didn't check the return value of port_buffer_size()) which
the app_server misinterpreted and quit itself... this fixes the hanging part
of bug #1298.
* But the input_server still wasn't restarted, because the Registrar had it
still listed as being running. Now, the Registrar checks not just periodically
for died teams, it will also check for it when a new application registers
itself. This fixes the rest of bug #1298.
* Removed the old (disabled) R5 style input_server launch mechanism from the
app_server.
* MessageLooper now prints a bit more information when a port is supposed to
have been deleted.
* The default implementation of MessageLooper::_GetLooperName() is now
returning the name of the semaphore of its BLocker instead of "unnamed
looper".
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22115 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Always check the return of the resize function
* Handle resize errors gracefully and ensure that the message stays intact
* Don't crash when printing a message that contains a field with no items (unlikely but possible in low memory situations)
* Fixed renaming fields - was completely broken and would have missed up field names and contents
* Some cleanup
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22047 a95241bf-73f2-0310-859d-f6bbb57e9c96
Now checks if such a message is present and avoids sending B_SILENT_RELAUNCH in this case, and also in the standard case with a ref.
This fixes bug #1387
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21987 a95241bf-73f2-0310-859d-f6bbb57e9c96
