how to fix fixme:thread:NtQueryInformationThread info class 16 not supported yet? - opensuse

I am using OpenSUSE, I installed wine on it, and .net 4.0 using wine tricks. I ported windows forms application to linux. My application is used to connect to devices. We use device drivers for it. I got the exception "fixme:thread:NtQueryInformationThread info class 16 not supported yet ?" Anybody please help me.

The only way to fix that is to implement ThreadIsIoPending class. Also note that 'fixme' is not an exception, but a diagnostic message, it doesn't mean that something critically bad happened. In your case it's likely it comes directly from .NET runtime or some support library.

Related

QT based Win7 app can't cope with the death of an I/O device

I'm writing a QT based native c++ app that uses QtSerialPort library under Win7. It communicates with it periodically(say every 5seconds).
Problem is: the device that my app connects to via serial port, has power loss issues(can't change this). When this happens my app becomes hung and immortal: can't be killed by windows task manager or by process hacker(a nice replacement for windows task manager)' termination facilities. Soft restart is the best solution at the hand.
Now how can my app cope with such device situation?
I would submit this question to Qt's interest mailing list (interest#qt-project.org). Since the QtSerialPort library is fairly new, bugs can appear when a wide user base starts using it. There is a good chance that the developers who wrote the library can give you a better solution or they find that this is a bug in their code and fix it.

Forced logout crash with Qt & Opengl

I can't find any documentation on this issue so I figured it was time for a question:
We are writing an application that uses Qt and Opengl with some help from a homebrew singleton class. We have had good luck with it so far but I've just recently run into an amusing situation where if I run the program on my Ubuntu machine it will force a logout.
We do nothing to the machine in terms of user modification. I have a feeling it has something to do with the way we are initializing things, possibly with our timer.
I was curious if anyone had any small insight they might be able to give. Is this a known issue within Qt or Ubuntu?
Note: I would give more information on the program but its very large and I only have a hint as to where to start.
Sounds like a driver or X11 bug that causes a server crash. By definition a client must not be able to crash the X server. However it seems you're experiencing exactly that. There's probably nothing wrong on your side.
What to do: Report the problem to the developers of Xorg and Mesa. Provide a test case, ideally in source code form (try to reduce your programm to the most minimal version that still causes the crash).

Porting getifaddrs to Win XP

I'm trying to port a MacOSX app to windows and I've come up against a problem around getifaddrs. Basically windows does not support it. I'm trying to figure a way to re-implement it (for AF_INET and AF_INET6) but the "equivalent" functionality on windows appears to be nothing like the MacOSX support.
Has someone done this sort of conversion before? If so is there a nice way I can get windows to report me interface info like MacOSX does?
The closest functions on Windows are GetAdaptersInfo and GetAdaptersAddresses. The MSDN documentation is pretty comprehensive, so you should find everything you need.
getifaddrs() is not a portable solution, so if you need to support multiple platforms, you should consider using getaddrinfo, which is POSIX- and Windows-friendly. It is a little more complicated at first glance, but it really isn't that bad. This SO question has some good answers and links on the topic. (In particular, the showip.c example on Beej's page is quite helpful, and here is a Windows example; note that it is missing an #include <stdio.h> at the top, and be sure to link against Ws2_32.lib.)
I've done it here, including a separate version for Wine as the IP version agnostic routines don't current work as expected,
http://code.google.com/p/openpgm/source/browse/trunk/openpgm/pgm/getifaddrs.c
LGPL 2.1 license
edit: Wine 1.3 fixes the issues encountered with the IPv4 & IPv6 friendly API.
maybe win32 port of libpcap can help you?
(or port of libnet, if one exists)

How to detect leaks under WinCE C/C+ runtime library?

I know the possibilities of basic leak detection for Win32 using the crtdbg.h header, but this header is unavailable in the CE CRT library headers (i'm using the lastest SDK v6.1).
Anyone knows how I can automatically detect leaks in a WinCE/ARMV4I configuration with VC 9.0? I don't want to override new/delete for my class hierarchy, I would prefer ready to use and tested code.
At work (developing WindowsCE based OS + Applications) we have created our own memory manager, roughly based on the Fluid Studios Memory Manager (the link which I found using SO!). I'm pretty sure with a few simple modifications you could adapt it to use on your platform.
Basically it doesn't override new and delete, but instead uses the preprocessor to add extra reporting to it. Then once the program exits it generates an output file of memory leaks.
You want to use either AppVerifier or Entrek CodeSnitch. I've had much better luck getting CodeSnitch working in a short period of time. The caveat there is I don't do a whole lot of WinMo - mostly vanilla CE. I believe there are connectivity issues with CodeSnitch and newer WinMo devices (Platman versus Corecon), but I also believe that Entrek either has a beta or a patch that works for it. My recommendation would be to call Entrek (don't email, they're busy so a call will be your quickest route to info) and only if you find that it won't work, then look into AppVerifier.
I think there is a SourceForge Project for this:
http://sourceforge.net/projects/crtdbg4wince/
If I understand your questin right, it is what you are looking for

Entrek CodeSnitch with Windows Mobile 5/6

I have emailed Entrek and they seem to be asleep.
Does anyone else here use Entrek CodeSnitch? If so, have you found a way to use it with Windows Mobile 5, 6, or 6.1 ?
I really need to verify my application doesn't have any memory leaks, etc. And CodeSnitch does a great job of it. But only with Windows Mobile 2003. :/
Thanks.
What's not working? Is it a client connectivity issue?
The older version used PlatMan for a communications layer, which is problematic from a Visual Studio standpoint (which ships with CoreCon), but if you have any tool installed that has Platman (eVC, Platform Builder) then that should still work fine since WinMo 5.x and 6.x are still based on CE 5.0.
I do know that Entrek has a newer version in beta (I have it) so you might try pinging them again. They tend to be pretty busy, but I've always gotten responses (though I know them well and personally, so that might not be any indicator for you).
I also see that they have their phone number posted on their web page. I'd give them a call. I do recall them saying the new version is supposed to address WinMo issues (I rarely use WinMo proper) so it's definitely worth a try.
I've not used CodeSnitch. But I have had success using the Application Verifier Tool to identify my leaks in WM5 and 6.
Getting it up and running can be a bit of a pain. But I find it to be a good tool and the price is right.
Here's a tutorial to get you started.
I've used CodeSnitch on windows mobile 5, 6 and 6.1 devices with no problems.
Make sure you have the v1.4 installed and applied the v1.4 patch which is referenced here.
Like ctackle says, you need an older communications layer called CoreCon. I've also found CETK has CoreCon in it as well and it's not as big as eVC or Platform builder.
You need to setup the device connection settings to use ActiveSync (both transport and startup server), it does not seem to matter what the connection is called so something like Pocket PC will work fine.
The other gotcha I found is that you need to edit the codesnitch and procman shortcuts and add "/targetcpu:armv4i" to the command line arguments for them to work on WM devices.
I have also found them recently to be non-responsive to support emails as well :(