Win API control accesses memory inappropriately when messaged from another thread - c

I know I'm not supposed to access a control from a thread that didn't create it, but I tried it anyway and got a really peculiar error. I did it in assembly, which everybody hates reading, so here's the equivalent code in C:
/* Function that returns the number of characters after startOfItem
that are not some delimeter. startOfItem[maxSize] is guaranteed to
be at a valid address and to be a delimiter. The function is defined
elsewhere and works perfectly. */
unsigned int getSizeOfItem(char* startOfItem, unsigned int maxSize);
/* This function runs in a worker thread. It has an exception handler that is
omitted here for clarity, and because it is never run anyway. */
void itemizeAndAddToListbox (HWND hListbox, char* strings, unsigned int size) {
while (size) {
unsigned int sizeOfItem = getSizeOfItem(strings, size);
strings[sizeOfItem] = 0; //overwrite the delimiting character with null
SendMessage( hListbox, LB_ADDSTRING, (WPARAM) 0, (LPARAM) strings );
/* passing a pointer to a different thread is a no-no, but SendMessage
does not return until the message is processed, so no disposal issues
are possible. And I happen to know that all addresses from *strings
to strings[sizeOfItem] remain valid. */
strings += sizeOfItem+1;
size -= sizeOfItem+1;
};
}
Believe it or not, this works perfectly from a thread that did not create hListbox until the very last item, at which point the listbox causes an access violation by reading strings[size+1]. It throws the exception in the UI thread (the one that created the listbox), ignoring the worker thread's exception handler. SendMessage() inappropriately returns 0 instead of the listbox error code.
I made this work by sending user-defined messages from the worker thread to the UI thread's window, which in turn sends the LB_ADDSTRING message with the very same parameters to the very same listbox, and it works perfectly. The exception hasn't happened yet when the message is sent from the UI thread, but that's such a random difference that I'm nervous about the proper working code as well. Anybody know what the listbox is doing accessing memory beyond the null-terminated end of the string in the first place, and what I can do to prevent it from doing so?

Since the SendMessage() serializes the call onto the receiving thread, then I would expect the exception to happen on the UI thread because that's the one adding the string.
MSDN SendMessage:
'The return value specifies the result of the message processing; it depends on the message sent.' This is not the listbox error code from teh exception will not be put into the message field unless the message-hander puts it there.
What happens to 'size' at the end if you call in with one string of size 1? Will 'size' not be set to -1, ie. not false?
Rgds,
Martin

Related

X11: _NET_FRAME_EXTENTS window property. Not consistent return with XCB

The code in question is similar to this SO topic: Get X11 window caption height. The link points to answer with Xlib code. The idea is to get window properties, _NET_FRAME_EXTENTS namely. The code waits untill the window manager will set the decoration sizes. The code in the answer skips all events till the property returned.
Basically I do the same with XCB. I want to know the decoration sizes of a window that I had just created. The pseudocode what I do with XCB:
cookie = xcb_get_property(...)
reply = xcb_get_property_reply(..., cookie, ...)
if(NULL == reply){
/* fail */
}
if(reply->type != type){
/* fail */
}
prop_size = xcb_get_property_value_length(reply);
prop_val = xcb_get_property_value (reply);
if(0 == prop_size){
/* fail */
}
if(/* not failed */){
copy returned data here
print and return success.
}
if(/* failed */)
then wait for events and skip them
repeat the above untill success
The problem is that sometimes values being returned as zeros, and sometimes the values are correct. As you can see from above code, the success condition is only when the type match and there is some data that are read. The request is checked with cookie so, as I understand, the reply belongs to the request. I do map the window and flush events before I call the above code.
The question is, how to get WM decorations properly with XCB?
I got tied to the linked SO topic. The answer in the topic do the right thing and gives a great insight but fails to execute it properly.
The solution is to wait for XCB_PROPERTY_NOTIFY event and compare the recieved atom with a _NET_FRAME_EXTENTS atom. If all checks went good, then WM has set the _NET_FRAME_EXTENTS property. Not earlier than that specific event is recieved, there is a sense to get values of the property. That is why I got zeroes in some invocations of the application. My original solution may get the property value earlier before WM sets the property.
Some pseudocode:
loop:
ev = xcb_wait_for_event(...);
...error checks...
if((ev->response_type & ~0x80) == XCB_PROPERTY_NOTIFY){
xcb_property_notify_event_t *pe = (xcb_property_notify_event_t*)ev;
if(pe->atom == {_NET_FRAME_EXTENTS atom}){
...get the _NET_FRAME_EXTENTS property...
}
}
...
loop end;

Kaa doesn't send event

I have set up an Kaa server and developed an application with the SDK. but application doesn't send Event massages.
this application should send license plate of the cars entered parking to server and also send an event to the another application(receiver app).
the application send data to server but doesn't send events.
whats the problem?
this is my code:
static void callback(void *context)
{
kaa_string_t plate;
kaa_user_log_record_t *log_record = kaa_logging_data_collection_create();
plate.data = "some license plate";
log_record->plate = &plate;
kaa_logging_add_record(kaa_client_get_context(context)->log_collector, log_record, NULL);
printf("%s uploaded\n", plate.data);
kaa_plate_detection_event_plate_event_t *plate_event = kaa_plate_detection_event_plate_event_create();
plate_event->plate = &plate;
kaa_error_t error_code = kaa_event_manager_send_kaa_plate_detection_event_plate_event(
kaa_client_get_context(context)->event_manager, plate_event, NULL);
//plate_event->destroy(plate_event);
printf("%s event sent\n", plate.data);
}
Problem Description
In the beginning of callback() you're defining kaa_string_t plate; ==>
It means that its memory is allocated on the stack.
Later in the same scope, you're creating a pointer to plate_event, and it will be used as argument to the event that you want to send.
Before you're sending the event, you're assigning plate_event->plate = &plate. It means that plate_event->plate is now pointing to an address on the stack.
Then, (according to what you wrote in the comments) you're sending the event using an asynchronous function. It means that the thread that is executing this function is not waiting for the message to be really sent - that's the meaning of an asynchronous function. Something else (probably a different thread, depending on the implementation of the send_event function) will take care of the sending. Therefore, it's not guarenteed that the message is sent before the next lines of code are executed.
In your case it's probable that before the message was sent, the scope of callback() ended. Therefore the memory of this scope is automatically freed and invalid from now, including kaa_string_t plate. Then at some point, the asynchronous sending is executing but it relies on an invalid memory because now plate_event->plate is pointing to a memory that was already freed.
Possible solution
Instead of allocating kaa_string_t plate on the stack, allocate it on the heap (malloc). Then the memory is valid until you free it yourself, when you're sure the message was already sent.
Something like that:
kaa_string_t *plate = malloc(sizeof(kaa_string_t));
strncpy(plate, "some license plate", sizeof(kaa_string_t));
...
// Now it's safe to do this:
plate_event->plate = plate;
// Sending event code
...

(Why) Does Windows "Calc.exe" lack a WndProc?

I am fiddling with wndprocs and WinSpy++ and i stumbled upon a strange thing with calc.exe.
It appears to lack a WndProc.
Here is my screenshot: a test program I made, the WinSpy++ window,, showing N/A, and the culprit.
Maybe the tool is a bit outdated, but the empirical evidence proves no WndProc is there.
I don't know if this is by design(this would be strange), or if I am missing something...
Here is referenced code:
Function FindWindow(title As String) As IntPtr
Return AutoIt.AutoItX.WinGetHandle(title)
End Function
Function GetWindowProc(handle As IntPtr) As IntPtr
Return GetWindowLong(handle, WindowLongFlags.GWL_WNDPROC)
End Function
In short (about your code): GetWindowLong() fails because you're trying to read an address in target process address space.
EXPLANATION
When GetWindowLong() returns 0 it means there is an error, from MSDN:
If the function fails, the return value is zero. To get extended error information, call GetLastError.
Check Marshal.GetLastWin32Error() and you probably see error code is ERROR_ACCESS_DENIED (numeric value is 0x5).
Why? Because GetWindowLong() is trying to get address (or handle) of window procedure (not in your code, but in target process, in theory it may even be default window procedure but I never saw an application main window that doesn't hanle at least few messages). You may use this trick (but I never tried!) to see if a window is using default procedure (you have an address or not), I don't know...someone should try.
Now think what WNDPROC is:
LRESULT (CALLBACK* WNDPROC) (HWND, UINT, WPARAM, LPARAM);
An address (valid in process A) is not callable in process B (where it makes no sense at all). Windows DLLs code segments are shared across processes (I assume, I didn't check but it's reasonable in the game between safety and performance).
Moreover CallWindowProc(NULL, ...) will understand that NULL as a special value to invoke window procedure for that window class (on HWND owner). From MSDN:
...If this value is obtained by calling the GetWindowLong function ...the address of a window or dialog box procedure, or a special internal value meaningful only to CallWindowProc.
How Microsoft Spy++ does it (and maybe WinSpy++ does not)? Hard to say without WinSpy++ source code. For sure it's not such easy like GetWindowLong() and right way should involve CreateRemoteThread() and to do LoadLibrary() from that but both Microsoft Spy++ and WinSpy++ source code aren't available (AFAIK) for further inspection...
UPDATE
WinSpy++ inspection/debugging is pretty off-topic with the question (you should post a ticket to developers, your source code may fail for what I explained above, you should - always - check error codes) but we may take a look for fun.
In InjectThread.c we see it uses WriteProcessMemory + CreateRemoteThread then ReadProcessMemory to read data back (not relevant code omitted):
// Write a copy of our injection thread into the remote process
WriteProcessMemory(hProcess, pdwRemoteCode, lpCode, cbCodeSize, &dwWritten);
// Write a copy of the INJTHREAD to the remote process. This structure
// MUST start on a 32bit boundary
pRemoteData = (void *)((BYTE *)pdwRemoteCode + ((cbCodeSize + 4) & ~ 3));
// Put DATA in the remote thread's memory block
WriteProcessMemory(hProcess, pRemoteData, lpData, cbDataSize, &dwWritten);
hRemoteThread = CreateRemoteThread(hProcess, NULL, 0,
(LPTHREAD_START_ROUTINE)pdwRemoteCode, pRemoteData, 0, &dwRemoteThreadId);
// Wait for the thread to terminate
WaitForSingleObject(hRemoteThread, INFINITE);
// Read the user-structure back again
if(!ReadProcessMemory(hProcess, pRemoteData, lpData, cbDataSize, &dwRead))
{
//an error occurred
}
Window procedure in "General" tab and in "Class" tab differs (in "Class" tab it correctly display a value). From DisplayClassInfo.c:
//window procedure
if(spy_WndProc == 0)
{
wsprintf(ach, _T("N/A"));
}
else
{
wsprintf(ach, szHexFmt, spy_WndProc);
if(spy_WndProc != spy_WndClassEx.lpfnWndProc)
lstrcat(ach, _T(" (Subclassed)"));
}
//class window procedure
if(spy_WndClassEx.lpfnWndProc == 0)
wsprintf(ach, _T("N/A"));
else
wsprintf(ach, szHexFmt, spy_WndClassEx.lpfnWndProc);
As you see they're different values (obtained in different ways). Code to fill spy_WndProc is in WinSpy.c and GetRemoteWindowInfo.c. Extracted code from GetRemoteInfo() in WinSpy.c:
GetClassInfoEx(0, spy_szClassName, &spy_WndClassEx);
GetRemoteWindowInfo(hwnd, &spy_WndClassEx, &spy_WndProc, spy_szPassword, 200);
Now in GetRemoteWindowInfo() we see a call to GetClassInfoExProc (injected in the other process):
pInjData->wndproc = (WNDPROC)pInjData->fnGetWindowLong(pInjData->hwnd, GWL_WNDPROC);
pInjData->fnGetClassInfoEx(pInjData->hInst,
(LPTSTR)pInjData->szClassName, &pInjData->wcOutput);
As you can see (please follow using source code) wcOutput is what is displayed in "Class" tab and wndproc what is displayed in "General" tab. Simply GetWindowLong() fails but GetClassInfoEx does not (but they do not necessarily retrieve same value because (if I'm not wrong) what you have in WNDCLASSEX is what you registered with RegisterClassEx but what you get with GetWindowLong() is what you hooked with SetWindowLong().
You are right. It does not have a WndProc(...) function. It is just simply using a DlgProc to process the dialog events. I now this as I have written 'server/thin client' code in C/C++ to capture direct calls into windows API functions like WndProc(...). Any Windows GUI function really - BeginPaint(...) as an example. I used CALC.EXE as a test and executable runs on server while GUI calls are relayed/returned to/from the thin client. Have only tested calc.exe versions thru Vista. There is a chance the newer versions have been 'programmed' differently - meaning not using Win32 SDK. But, even MFC is just a shell to the Win32 SDK,

sockets using libev

Iam looking to write a socket program based on libev. I noticed that several examples as stated in https://github.com/coolaj86/libev-examples/blob/master/src/unix-echo-server.c use the call backs based on init. For example,
main() {
......
ev_io_init(&client.io, client_cb, client.fd, EV_READ|EV_WRITE);
ev_io_start(EV_A_ &server.io);
}
static void client_cb (EV_P_ ev_io *w, int revents)
{
if (revents & EV_READ)
{
....
} else if (revents & EV_WRITE) {
......
}
}
My question comes from the expected behaviour, say for example, all that i read when in EV_READ is stored in a linked list. Lets say I keep getting free flow of packets to read, will i ever get a chance to get into EV_WRITE? I have to send out all that I recv through read to another socket. So Will it be once EV_READ and second time EV_WRITE? In other words when will EV_WRITE be unblocked? Or do I need to block EV_READ for EV_WRITE to be called. Can someone help me understand this?
I think you should keep write callback separated from read callback:
main() {
ev_io_init(&read.io, read_cb, client.fd, EV_READ);
ev_io_init(&write.io, writead_cb, client.fd, EV_WRITE);
ev_io_start(EV_A_ &read.io);
ev_io_start(EV_A_ &write.io);
}
This is my solution.
To answer shortly: If you allways check for one type of event first and then have an else
if for the other you risk starvation. In general I would check for both, unless the specified protocol made it impossible for both to be activated at the same time.
Here is a more iffy answer:
The link in your question does not contain a code structure such as your question. The client https://github.com/coolaj86/libev-examples/blob/master/src/unix-echo-client.c does have a similar callback. You will notice it disables write events, when it has written once.
// once the data is sent, stop notifications that
// data can be sent until there is actually more
// data to send
ev_io_stop(EV_A_ &send_w);
ev_io_set(&send_w, remote_fd, EV_READ);
ev_io_start(EV_A_ &send_w);
That looks like an attempt to avoid starvation of the pipe READ event branch. Even though Im not very familiar with libev, the github examples you linked to do not seem very robust. E.g static void stdin_cb (EV_P_ ev_io *w, int revents)does not use the return value of getline() to detect EOF. Also the send() and recv() socket operation return values are not inspected for how much was read or written (though on local named pipe streams the amounts will most likely match the amounts that were requested). If this was later changed to a TCP based connection, checking the amounts would be vital.

Sharing a DNSServiceRef using kDNSServiceFlagsShareConnection stalls my program

I'm building a client using dns-sd api from Bonjour. I notice that there is a flag called kDNSServiceFlagsShareConnection that it is used to share the connection of one DNSServiceRef.
Apple site says
For efficiency, clients that perform many concurrent operations may want to use a single Unix Domain Socket connection with the background daemon, instead of having a separate connection for each independent operation. To use this mode, clients first call DNSServiceCreateConnection(&MainRef) to initialize the main DNSServiceRef. For each subsequent operation that is to share that same connection, the client copies the MainRef, and then passes the address of that copy, setting the ShareConnection flag to tell the library that this DNSServiceRef is not a typical uninitialized DNSServiceRef; it's a copy of an existing DNSServiceRef whose connection information should be reused.
There is even an example that shows how to use the flag. The problem i'm having is when I run the program it stays like waiting for something whenever I call a function with the flag. Here is the code:
DNSServiceErrorType error;
DNSServiceRef MainRef, BrowseRef;
error = DNSServiceCreateConnection(&MainRef);
BrowseRef = MainRef;
//I'm omitting when I check for errors
error = DNSServiceBrowse(&MainRef, kDNSServiceFlagsShareConnection, 0, "_http._tcp", "local", browse_reply, NULL);
// After this call the program stays waiting for I don't know what
//I'm omitting when I check for errors
error = DNSServiceBrowse(&BrowseRef, kDNSServiceFlagsShareConnection, 0, "_http._tcp", "local", browse_reply, NULL);
//I'm omitting when i check for errors
DNSServiceRefDeallocate(BrowseRef); // Terminate the browse operation
DNSServiceRefDeallocate(MainRef); // Terminate the shared connection
Any ideas? thoughts? suggestion?
Since there are conflicting answers, I dug up the source - annotations by me.
// If sharing...
if (flags & kDNSServiceFlagsShareConnection)
{
// There must be something to share (can't use this on the first call)
if (!*ref)
{
return kDNSServiceErr_BadParam;
}
// Ref must look valid (specifically, ref->fd)
if (!DNSServiceRefValid(*ref) ||
// Most operations cannot be shared.
((*ref)->op != connection_request &&
(*ref)->op != connection_delegate_request) ||
// When sharing, pass the ref from the original call.
(*ref)->primary)
{
return kDNSServiceErr_BadReference;
}
The primary fiels is explained elsewhere:
// When using kDNSServiceFlagsShareConnection, there is one primary _DNSServiceOp_t, and zero or more subordinates
// For the primary, the 'next' field points to the first subordinate, and its 'next' field points to the next, and so on.
// For the primary, the 'primary' field is NULL; for subordinates the 'primary' field points back to the associated primary
The problem with the question is that DNSServiceBrowse maps to ref->op==browse_request which causes a kDNSServiceErr_BadReference.
It looks like kDNSServiceFlagsShareConnection is half-implemented, because I've also seen cases in which it works - this source was found by tracing back when it didn't work.
Service referenses for browsing and resolving may unfortunately not be shared. See the comments in the Bonjour documentation for the kDNSServiceFlagsShareConnection-flag. Since you only browse twice I would just let them have separate service-refs instead.
So both DNSServiceBrowse() and DNSServiceResolve() require an unallocated service-ref as first parameter.
I can't explain why your program chokes though. The first DNSServiceBrowse() call in your example should return immediately with an error code.
Although an old question, but it should help people looking around for answers now.
The answer by vidtige is incorrect, the may be shared for any operation, provided you pass the 'kDNSServiceFlagsShareConnection' flag along with the arguments. Sample below -
m_dnsrefsearch = m_dnsservice;
DNSServiceErrorType mdnserr = DNSServiceBrowse(&m_dnsrefsearch,kDNSServiceFlagsShareConnection,0,
"_workstation._tcp",NULL,
DNSServiceBrowseReplyCallback,NULL);
Reference - http://osxr.org/android/source/external/mdnsresponder/mDNSShared/dns_sd.h#0267

Resources