After a lot work invested in getting CefNet to work on Windows, I wanted to port my NET 7 app to Linux (Ubuntu). To my understanding CefNet is the only implementation that will work on Linux.
I got to a point where I am getting the exception below. Spying on source code using DotPeek leaves me under the impression that CefNet won't work in "headless" mode but will require "X server". Not sure why this would be necessary for off-screen rendering.
Any insight is appreciated.
Unhandled exception. System.InvalidOperationException: Operation is not valid due to the current state of the object.
at CefNet.CefScreenInfo.GetPrimaryScreenInfo()
at CefNet.Internal.WebViewGlue.GetScreenInfo(CefBrowser browser, CefScreenInfo& screenInfo)
at CefNet.Internal.CefRenderHandlerGlue.GetScreenInfo(CefBrowser browser, CefScreenInfo& screenInfo)
at CefNet.CefRenderHandler.GetScreenInfoImpl(cef_render_handler_t* self, cef_browser_t* browser, cef_screen_info_t* screen_info)
Related
As the title says, this post is meant to highlight two bugs that weren't there before last CN1 .jar updates:
Launching a codenameone app in debug mode fails
New or modified rounded rectangle border defined through the theme file are forced in top only mode
Launching a codenameone app in debug mode fails
I'll start with the 1st one as it is the most disturbing.
On Eclipse, launching the app in debug mode results in the following error (that I wasn't getting last week):
ERROR: transport error 202: connect failed: Connection refused
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [debugInit.c:735]
Initially, I thought that the socket was failing to initialize as the port was being used. That is also what you would mostly find on internet. So I checked the command line used to find out which port the socket was trying to connect to so that I can check if that port was available:
C:\Program Files\Java\jdk-13.0.1\bin\javaw.exe -agentlib:jdwp=transport=dt_socket,suspend=y,address=localhost:54499 "-javaagent:C:\Users\Roman\eclipse\jee-2019-09\eclipse\configuration\org.eclipse.osgi\1095\0\.cp\lib\javaagent-shaded.jar" -Dfile.encoding=UTF-8 -classpath "D:\Work\Software_workspaces\Eclipse_IDE\Selisys\FirstOnPersonalPC\JavaSE.jar;D:\Work\Software_workspaces\Eclipse_IDE\Selisys\FirstOnPersonalPC\bin;D:\Work\Software_workspaces\Eclipse_IDE\Selisys\FirstOnPersonalPC\lib\CLDC11.jar;D:\Work\Software_workspaces\Eclipse_IDE\Selisys\FirstOnPersonalPC\lib\CodenameOne.jar;D:\Work\Software_workspaces\Eclipse_IDE\Selisys\FirstOnPersonalPC\lib\impl\cls;D:\Work\Software_workspaces\Eclipse_IDE\Selisys\FirstOnPersonalPC\lib\impl\stubs;D:\Work\Software_workspaces\Eclipse_IDE\Selisys\FirstOnPersonalPC\native\internal_tmp" com.codename1.impl.javase.Simulator be.selisys.rdf.firstonpersonalpc.FirstOnPersonalPC
We can see that it is attempting to use port 54499 (in fact, in gets incremented by 1 at each command line call). Now the funny thing is that this port (and the many following ones) is (are) effectively free!
I tried things such as rebooting Eclipse, my computer, check the dt_socket.dll, ... but none of that helped. After hours thought, I noticed the debug mode was working on other applications, but not on CodenameOne ones.
I then moved to another computer:
Turned off the internet, ran the debugger on a CN1 app ==> Works fine
Turned the internet back on, send a built to get the jars updated, ran the debugger again ==> same error as above :(
Since I now know that it is obviously related to CN1 jars last update. Have you got any idea on how to solve that? How much time should we expect for a solution to come up? Any idea of a workaround? Maybe I can use the old jars, if there is a place to find them.
New or modified rounded rectangle border defined through the theme file are forced in top only mode
That is less important, but still annoying: basically, we can't use rounded rectangle borders using theme unless we have set them before the recent updates (I have no clue on since when the bug exists except that it is no older than 1 month). If you create/edit a rounded rectangle border, I will automatically be set to top only mode upon save. The current workaround I am using is creating a hard coded RoundRectBorder.
As above, the bug appears on any computer which get its jars updated.
Hope pointing these out will help them getting resolved earlier. :)
Cheers
I am a beginner to DBus and wrote one sample application using dbus but i am facing a weird problem. My app is running fine on guest os as Ubuntu (On virtual box with windows host ) but the same app is not working on standalone Ubuntu system (also tried on meego, no luck thr as well).
Then, i verified the obvious doubts on dbus, glib libraries versions. Its same on both the environments, and the issue is consistent. I mean the app always runs without any prob on virtual box and always crashes on the standalone ubuntu.
Here is the brief desc about the issue.
App is supposed to send 150 signals on dbus and another app is
receiving these signals. (No issues here in send & receive).
I have an array of DbusMessage[150] (also tried with the list of 150 DBusMessage)...appending the arguments on to the dbus msg and sending on to bus..one at a time...no looping...
The sequence of dbus APIs are all correct and verified by referencing multiple sample source code.
All of above works fine, but on the standalone ubuntu system, i can always see segmentation fault, on dbus_connection_send() call.
I reverified everypossible places where in "seg faults" can happen and it all looks fine to me. This is how i am appending my arg to dbus message.
dbus_message_append_args(pDbusMsg, DBUS_TYPE_ARRAY, DBUS_TYPE_BYTE, &pData, sizeof(pData),
DBUS_TYPE_INVALID) != TRUE)
then connection send..and then calling dbus_connection_flush(). Also as my app has to send the same message again (but not immediately), i am re registering the same signal by calling dbus_message_new_signal()..i have verified all the pointers / memory / dbusmessage..everything looks fine and works fine on virtualized ubuntu os.
Just to add, i tried sending with dbus_connection_send_preallocated() and it works fine for few messages(10-15~), but not consistent enough.
Have you ever had this kind of issue, please let me know any clue to solve this prob....Any help would be appreciated or any examples/tutorials as well taking into consideration I'm just starting out with dbus :P
Thanks
I dont know if you have heard about dbus related debugging tools. For beginning you can try calling the exposed functions using some dbus-debugging-tool. If it doesnt throw segmentation fault when you call using the tool, then probably you should look for issues in your code. Otherwise you should check things related to environment.
One such tool is - DFeet
Another such debugger(commandline based) is provided by Qt people as well.
I've got a strange problem I haven't seen before. I can open an OpenFileDialog in Windows 7 without any problems. However, when I try my app on Windows XP, calling OpenFileDialog.ShowDialog() immediately crashes the application. It just vanishes! When running from the debugger, I don't get any unhandled exceptions. If I wrap the code in a try/catch block, nothing gets caught. I have also checked all thrown exceptions in Debug -> Exceptions, but nothing pops up. I'll try some of the other suggestions in the answers below and will report back.
Does anyone know how to resolve this problem? I found a post about something similar, but it was the opposite problem. I'll try tweaking the desktop settings to see if it's related to that, but I am dubious.
EDIT -- as a sanity check, I wrote a test WPF application that displays an OpenFileDialog directly via the main window as well as another Window that can be displayed by the main window. It totally works fine under Windows XP. So now I'm really confused. I have verified that I'm not doing something stupid like trying to display the dialog from a worker thread. The OpenFileDialog displays briefly, then disappears along with the application.
EDIT -- I'm going to try to reproduce this problem on another XP computer. For now, I'll try Windows XP mode and we'll see what happens.
I got a similar error when a DLL crashes when I open a OpenFileDialog. It turned out that OpenFileDialog changed the working directory so my dll tried to write to a relative file that did not exist.
Do you see any "First Chance" exceptions in the Output? Any entries in the event log? Does the default path you're using exist on the XP machine?
Try adding a handler to the App Domain's UnhandledException
Does the same happen when you use a brand new, stock FileOpenDialog without any tweaks? What about from a brand new app which does nothing but show a file open dialog?
See Galet's post
I cannot tell you what exactly the problem is, but here's what you could do to get a clue what's really happening. I assume you're using VS2008 or 2005.
1.Switch to release mode
2.Go to Debug\Exceptions, and mark all "Thrown" exceptions, like illustrated here: http://vvcap.net/db/JbWS_tzy2IpBoI7R7amm.htp
3.Run executable in debugger, ignore the warnings from VS that there's no debug info
It does seem that there's a win32 exception thrown some time during execution, but this way or another, you will get one or more messages from debugger explaining what kind of exception happened and where. In most cases those messages make it pretty clear what exactly went wrong
EDIT: One thing I forgot to mention is that unmanaged debugging must also be turned on, such like here (when you start program directly from IDE) or here (when you attach to running process)
link|edit|flag edited Apr 12 '09 at 22:32
answered Apr 10 '09 at 19:01
galets
1,2201924
I have a WinForms application in which I want to be able to provide an HTML editing feature. So I've translated Lutz Roeder's HTML Writer from C# into VB.NET, and converted it from a windows form into a Custom User Control, which is now hosted in an MDI child form.
It all works fine until I close the parent MDI, in which case it crashes, and I cannot trap the exception.
I've isolated the editor control into a little vanilla WinForms app that doesn't do anything else, and verified that the problem still occurs.
I've also switched on Unmanaged Code Debugging (I'm using VS2010, compiling for x86 and Framework 3.5), and all I get is this:
Windows has triggered a breakpoint in HtmlEditorMdi.exe.
This may be due to a corruption of the heap, which indicates a bug in HtmlEditorMdi.exe or any of the DLLs it has loaded.
This may also be due to the user pressing F12 while HtmlEditorMdi.exe has focus.
The output window may have more diagnostic information.
The only thing other thing I've noticed is that if I leave a long interval after opening the form containing the editor, it doesn't crash.
What I'd really appreciate is some ideas about how to go looking for this problem. It may be of course that I've made a mistake in the C# to VB conversion, but I'm struggling to know where to look.
Edit:
I've run the app with the debugger attached, and it doesn't give me anything useful.
All I get is the Windows 'Application has stopped working' message, with this in the problem details:
Problem signature:
Problem Event Name: APPCRASH
Application Name: HtmlEditorMdi.exe
Application Version: 1.0.0.0
Application Timestamp: 4cfb74c7
Fault Module Name: mscorwks.dll
Fault Module Version: 2.0.50727.4952
Fault Module Timestamp: 4bebd49a
Exception Code: c0000005
Exception Offset: 000022b5
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 2057
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
I can see that it's an access violation, but even if I go Debug > Exceptions > Win32 Exceptions, and tick c0000005, I don't get anything useful when it breaks - just 'no source available'.
The first message you quoted is produced by the Windows heap manager when it discovers that the internal heap structure is destroyed. It displays that diagnostic when it sees that a debugger is attached. The 2nd quoted block is what happens when it bypasses the diagnostic (no debugger attached), it bombs on a hardware exception when it tries to release memory in the corrupted heap anyway.
The trouble with heap corruption is that the real damage is done a long time before the diagnostic is generated. You can see a stack trace leading up to the diagnostic in the Call Stack window, you'll need to enable the Microsoft symbol server to get meaningful symbols for the Windows functions. But it won't tell you anything useful about the code that really caused the damage, that requires a time machine.
This kind of heap corruption is invariably caused by unmanaged code. The AccessViolation exception is a well known scourge to C/C++ programmers and a very large reason why managed code became popular. While Lutz' source code is all managed, it contains a lot of P/Invoke and COM interface declarations. There is no good way to debug them, you don't have the source code.
Getting one of those declarations subtly wrong when you converted them to VB.NET is certainly one way this could happen. It could also well be that the bug was always there but reared its ugly head just now. Lucky you. Btw, I don't think the code is 64-bit clean, force it to run in 32-mode for a possible quick fix. For your main EXE project: Project + Properties, Compile tab, scroll down, Advanced Compile Options, Target CPU = x86. This is only relevant if you run on a 64-bit version of Windows.
Other than that, I'd recommend you just use the C# project as-is. Mixing languages in a solution is a very well supported scenario in .NET.
The windbg debugger is the "big gun" for this sort of problem. It can frequently give you clues by telling you about handled exceptions etc. The only problem with it is that it's not easy to use and has a very high learning curve.
Vista SP1
Visual Studio 2008 SP1
.NET 3.5 SP1
C#
I have a winforms app I'm playing with that uses a SerialPort object as a private variable. When the application is compiled and executed, it works great. It also works running in debug mode wihtout any breakpoints. 90% of the time when I stop at a breakpoint and try to step through code I get an 'unhandled exception ocurred' dialog with these details:
System.ObjectDisposedException was unhandled
Message="Safe handle has been closed"
Source="mscorlib"
ObjectName=""
StackTrace:
at Microsoft.Win32.Win32Native.SetEvent(SafeWaitHandle handle)
at System.Threading.EventWaitHandle.Set()
at System.IO.Ports.SerialStream.AsyncFSCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOverlapped)
at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)
InnerException:
The frustrating thing is, I do not have to be stepping over serial-related code! I just have to have done something with the port. So I might read a string, manipulate the string, add two numbers together, whatever, and then BANG.
Again, this works just fine when NOT debugging, or when debugging wihtout any breakpoints. There seems to be something about stopping at a breakpoint that makes the CLR dispose the SerialStream on a different thread.
There is a lot of chatter online about problems with renoving USB devices causing this. But I'm using the build-in motherboard port on COM1.
I don't think I had this issue in .NET 2.0 so I may have to go back to that...
I need to simplify the application quite a bit before I can post code - but has anyone seen behavior like this in the debugger before?
Thanks so much!
I had the same problem just this morning. Surprisingly, it simply has gone away when I DISABLED the following options in VS2008 Tools->Options->Debugging->General:
"Enable the exception assistant"
"Enable .NET Framework source stepping"
"Step over properties and operators"
"Enable property evaluation and other implicit function calls"
I have no idea why, but it worked for me.
Perhaps your port is getting closed by the OS as it does not get a response from your application (it is stopped at a breakpoint).
Well I'm not so sure this is an answer, but there was definately something about that project. It was originally written in 2.0 and converted to 3.5 by VS2008. I created a new project in C#-Express 2008 adding the original classes one-by-one and it works like a charm now! No idea what is different.
I have this too. This must be some kind of bug with the debugger. The above advice worked: Disable the "Enable property evaluation and other implicit function calls."
I have a class with properties that do serial I/O. I thought that perhaps the debugger was helpfully trying to display the property value when I hovered the mouse over it, thus doing the IO from the debugger thread. But that doesn't seem to be the case. I'm really unsure what the cause is.
I had the same problem and did the following:
serialPortLock = Monitor.TryEnter(serialPort, 3000);
Thread.Sleep(5);
serialPort.Write(msg, 0, msg.Length);
and the same for my Read().
Looks like it's a good workaround for me!