Wine error: Application tried to create a window, but no driver could be loaded - wine

I made a fcgi-isapi bridge, which I compile with wineg++ (keyword winelib). It is running a pure Win32 isapi extension using LoadLibrary/GetProcAddress. This works fine for a simple demo isapi dll, but not for a more complex one, where wine crashes somewhere inside the dll. WINEDEBUG=+olerelay,+storage,+relay gives me the following output:
0009:Call KERNEL32.InterlockedIncrement(00000150) ret=1001eebe
0009:Call KERNEL32.UnhandledExceptionFilter(0033f428) ret=7bc8e2f5
wine: Unhandled page fault on write access to 0x00000150 at address 0x7b8716bd (thread 0009), starting debugger...
Application tried to create a window, but no driver could be loaded.
Make sure that your X server is running and that $DISPLAY is set correctly.
couldn't load main module (0)
0009:Ret KERNEL32.UnhandledExceptionFilter() retval=00000000 ret=7bc8e2f5
Unhandled exception: page fault on write access to 0x00000150 in 32-bit code (0x7b8716bd).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:7b8716bd ESP:0033f8cc EBP:0033f8e0 EFLAGS:00010246( R- -- I Z- -P- )
EAX:00000001 EBX:00000000 ECX:00000000 EDX:00000150
ESI:0033f8fc EDI:0033f8d4
Stack dump:
0x0033f8cc: 7bc6592e 00000150 00000000 7ca3c7d4
0x0033f8dc: 00000000 0033fdc8 7b823b61 7b8be9d4
0x0033f8ec: 000102d1 0033f8f4 1001eebe 00000150
0x0033f8fc: 7ef82158 7ca3c7d0 f775d2c8 0033faac
0x0033f90c: 7bcd7208 00000000 f775c2b1 0000000f
0x0033f91c: 7bcbbed8 1004e06c 00000002 00115760
Backtrace:
=>0 0x7b8716bd in kernel32 (+0x616bd) (0x0033f8e0)
1 0x7b823b61 in kernel32 (+0x13b60) (0x0033fdc8)
2 0x7ef813d0 (0x0033fe18)
3 0x7ef815f5 (0x0033fe60)
4 0x7b85e84c in kernel32 (+0x4e84b) (0x0033fe78)
5 0x7b85f903 in kernel32 (+0x4f902) (0x0033feb8)
6 0x7bc77600 (0x0033fed8)
7 0x7bc7a59d (0x0033ffa8)
8 0x7bc775de (0x0033ffc8)
9 0x7bc4c65e (0x0033ffe8)
(tested with Wine 1.4.1 and 1.6.2, both give exactly the same output (only some different numbers)
My questions:
What happens really and how can I figure out the reason for the page fault error?
Does wine try to run a graphical debugger or is the dll itself trying to create a X11 object? And why does it fail? This installation is running in a 32bit chroot environment on a 64bit host, but I called xhost + and tested X11 using xlogo, gedit and even with a Win32 GUI application using Wine. There doesn't seem to be any X11 problem.
Update: here is the link to the source: http://gist.github.com/daald/5f37de8352e1c8ca62db

Try
wineconsole --backend=curses fastcgi-to-isapi.exe
As this post describes:
Wine has three options to run apps in command line mode:
On the bare linux console (wine)
On the linux console with curses (wine wineconsole --backend=curses)
In a win32 window (wine wineconsole --backend=user)
For wineconsole, the user backend is the default, that's why your
command line tried to open a window.
It does however not print the output of the program. If you need the output, you can first start wineconsole in interactive mode, then run the exe from there:
me#mycomputer:~$ wineconsole
Microsoft Windows 6.1.7601 (3.0)
Z:\home\me> HelloWorld.exe
Hello World!
Obviously not a good solution if you want to do it programmatically though.

As per this post, wine is meant for graphical programs. To run your program without a graphical interface, use wineconsole instead, e.g.
wineconsole fastcgi-to-isapi.exe
See: Text mode programs (CUI: Console User Interface).
Alternatively use a X virtual framebuffer, see: Run wine totally headless.

Related

'SB-KERNEL:UNKNOWN-PARSE-TYPE' when connecting Vim to SBCL using Vlime

I have Vim 8.0.1365 with Vlime plugin (065b95f) installed and an SBCL (1.2.11) session with the start-vlime.lisp loaded, running on macOS 10.14.6 (18G87).
When I connect from Vim using \cc, the SBCL session shows vlime-sbcl - New connection from #<AIO-SBCL:AIO-FD {10048DFD63} (so the connection works) but then the debugger is invoked with an SB-KERNEL:PARSE-UNKNOWN-TYPE condition signalled.
The debugger restarts are:
0: [REMOVE-FD-HANDLER] Remove #<SB-IMPL::HANDLER INPUT on descriptor 6: #<FUNCTION AIO-SBCL::SOCKET-INPUT-CB>>
1: [ABORT ] Exit debugger, returning to top level.
(VLIME-SBCL::SOCKET-ERROR-CB #<unavailable argument> #<SB-KERNEL:PARSE-UNKNOWN-TYPE {1004BE9B23}>)
I've tried both restart options. Removing the handler gives no response, and aborting returns SBCL to the * prompt.
The connection appears to exist in Vim (though there is no success message) and can be selected when using the \ss command (I tested on (+ 3 3)).
The SWANK window just displays a -- for each use of \ss and an error message below shows:
Error detected while processing function vlime#plugin#SendToREPL[100]..vlime#ui#input#MaybeInput[33]..<SNR>42_CheckInputValidity[2]..<SNR>32_SendToREPLInputComplete:
line 2:
E716: Key not present in Dictionary: ListenerEval, [a:content, function('s:OnListenerEvalComplete')]))
E116: Invalid arguments for function(a:conn.ListenerEval, [a:content, function('s:OnListenerEvalComplete')]))
E116: Invalid arguments for function vlime#WithThread
I don't have much experience with SBCL or Lisp - this is basically a hurdle at the starting line.
What does the first restart option mean?
The PARSE-UNKNOWN-TYPE condition seems uncommon from a Google search, and not at all in relation to Vlime. What are some next steps I can take to work this out?
(Posting the comment as an answer)
A common source of error when dealing with client/server protocols is a mismatch in versions for the different parts involved. The gihub page for vlime lists dependencies and supported implementations, I'd start from there.
Also, try starting sbcl in a standalone terminal (first install quicklisp, use "rlwrap sbcl" for readline support) and then load Swank manually:
(ql:quickload :swank)
Create a server
(swank:create-server :port 4005)
And connect to it, so you can still debug errors from the terminal if there are problems with the client/server interface.

Why do OpenGL-based VTK targets in drake executed via `bazel test` sometimes fail on Linux?

While a binary works with bazel run, when I run a test using bazel test, such as:
$ bazel test //systems/sensors:rgbd_camera_test
I encounter a slew of errors from VTK / OpenGL:
ERROR: In /vtk/Rendering/OpenGL2/vtkXOpenGLRenderWindow.cxx, line 820
vtkXOpenGLRenderWindow (0x55880715b760): failed to create offscreen window
ERROR: In /vtk/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, line 816
vtkXOpenGLRenderWindow (0x55880715b760): GLEW could not be initialized.
ERROR: In /vtk/Rendering/OpenGL2/vtkShaderProgram.cxx, line 453
vtkShaderProgram (0x5588071d5aa0): Shader object was not initialized, cannot attach it.
ERROR: In /vtk/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, line 1858
vtkXOpenGLRenderWindow (0x55880715b760): Hardware does not support the number of textures defined.
May I ask why this happens?
(Note: This post is a means to migrate from http://drake.mit.edu/faq.html to StackOverflow for user-based questions.)
The best workaround at the moment is to first mark the test as as local in the BUILD.bazel file, either with local = 1, or tags = [.., "local"]. Doing so will make the specific target run without sandboxing, such that it has an environment similar to that of bazel run.
As an example, in systems/sensors/BUILD.bazel:
drake_cc_googletest(
name = "rgbd_camera_test",
# ...
local = 1,
# ...
)
If this does not work, then try running the test in Bazel without sandboxing:
$ bazel test --spawn_strategy=standalone //systems/sensors:rgbd_camera_test
Please note that you can possibly add --spawn_strategy=standalone to your ~/.bazelrc, but be aware that this means your development testing environment may deviate even more from other developer's testing environments.

initramfs init has generated signal 11 but has no handler for it

I built an embedded Linux kernel 2.6.19 on powerpc MPC860 CPU. I created a initramfs.cpio with only one "init" file in the / directory(no other files and no other directories). The init is cross-compiled to an elf format file. The init only set int i=0 and return 0.
All I want to do is to make sure the kernel can successfully call this init. Then I will add more stuff in the file system later.
But the serial port output error message "init has generated signal 11 but has no handler for it".
I have BDM interface connected to the board. The serial port is OK. gdb is OK. I cannot set breakpoint to the kernel_execve() because I use u-boot "bootm " command to boot the kernel.
Is there any method to debug it?

How to change boot partition for Beaglebone Black after flashing Debian 8.4 to eMMC?

I'm trying to get the current Debian 8.4 SD card image onto my Beaglebone Black's eMMC. The flashing itself worked flawlessly by enabling (uncommenting) this line in the /boot/uEnv.txt file:
cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh
Flashing completed successfully with blinking LED's as described in the HowTo. Next, I connected a serial-USB cable to the J1 connector in order to see the boot process in Putty's serial console. The system starts to boot but then stops with an error message:
Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
[line above repeats multiple times]
Begin: Running /scripts/local-block ... done.
done.
Gave up waiting for root device. Common problems:
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
- Check root= (did the system wait for the right device?)
- Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/mmcblk1p1 does not exist. Dropping to a shell!
I then get an (initramfs) prompt. From there, I figured out that mmcblk1p1 is not the right partition, it should be mmcblk0p1 instead. I think this is because of a different enumeration when the SD card is removed.
Now the big question: How and where can I set the partition the system starts from? It must be defined somewhere. I can mount the root partition mmcblk0p1 and edit files from the prompt, so I hope that there's just a small config file I need to tweak. Do I need to add something to the /boot/uEnv.txt file? (I already commented out the flasher script after flashing, of course).
Thanks for your help!
It should be as easy as editing uEnv.txt.
There should be a line containing: root=/dev/mmcblk1p1 - just edit that to say /dev/mmcblk0p1.
The current version of the flasher script (Dec 2019) changes the boot designation to eMMC automagically upon successful completion of the flash.

QEMU simple backend tracing dosen't print anything

I'm doing get simple trace file from QEMU.
I followed instructions docs/tracing.txt
with this command "qemu-system-x86_64 -m 2G -trace events=/tmp/events ../qemu/test.img"
i'd like to get just simple trace file.
i've got trace-pid file, however, it dosen't have anything in it.
Build with the 'simple' trace backend:
./configure --enable-trace-backends=simple
make
Create a file with the events you want to trace:
echo bdrv_aio_readv > /tmp/events
echo bdrv_aio_writev >> /tmp/events
Run the virtual machine to produce a trace file:
qemu -trace events=/tmp/events ... # your normal QEMU invocation
Pretty-print the binary trace file:
./scripts/simpletrace.py trace-events trace-* # Override * with QEMU
i followd this instructions.
please somebody give me some advise for this situation.
THANKS!
I got same problem by following the same document.
https://fossies.org/linux/qemu/docs/tracing.txt
got nothing because
bdrv_aio_readv and bdrv_aio_writev was not enabled by default, at least the version I complied, was not enabled. you need to open trace-events under source directory, looking for some line without disabled, e.g. I using:
echo "load_file" > /tmp/events
Then start qemu,
after a guest started, I run
./scripts/simpletrace.py trace-events trace-Pid
I got
load_file 1474.156 pid=5249 name=kvmvapic.bin path=qemu-2.8.0-rc0/pc-bios/kvmvapic.bin
load_file 22437.571 pid=5249 name=vgabios-stdvga.bin path=qemu-2.8.0-rc0/pc-bios/vgabios-stdvga.bin
load_file 10034.465 pid=5249 name=efi-e1000.rom
you can also add -monitor stdio to qemu command line, after it started, you can the following command in qemu CLI:
(qemu) info trace-events
load_file : state 1
vm_state_notify : state 1
balloon_event : state 0
cpu_out : state 0
cpu_in : state 0
1 means enabled events.
Modify the trace-events file in the source tree
As of v2.9.0 you also have to remove the disable from the lines you want to enable there, e.g.:
-disable exec_tb(void *tb, uintptr_t pc) "tb:%p pc=0x%"PRIxPTR
+exec_tb(void *tb, uintptr_t pc) "tb:%p pc=0x%"PRIxPTR
and recompile.
Here is a minimal fully automated runnable example that boots Linux and produces traces: https://github.com/cirosantilli/linux-kernel-module-cheat
For example, I used the traces to count how many boot instructions Linux has: https://github.com/cirosantilli/linux-kernel-module-cheat/blob/c7bbc6029af7f4fab0a23a380d1607df0b2a3701/count-boot-instructions.md
I have a lightly patched QEMU as a submodule, the key commit is: https://github.com/cirosantilli/qemu/commit/e583d175e4cdfb12b4812a259e45c679743b32ad

Resources