[support]

Hi,

Based on your log it looks like you are out of free space on your Linux machine. Note that the kernel sources and symbols need several gigabytes of space. Could you please try freeing up some space (e.g. adding another virtual disk and mounting /usr/src there)? Does it solve the problem? You can check your free space on Linux using the ‘df -h’ command.

[support]

Hi,

Sorry, looks like there is a bit of confusion here. Please let me know if I understand correctly that:
1. Touch screen works if you launch the app from the console.
2. Touch screen does not work if you launch the app using SmarTTY.

If that is correct, please obtain the ‘env’ output from the console (not using SmarTTY). E.g. run “env > /tmp/env.log” in the console and then cat /tmp/env.log with SmarTTY to copy-paste its contents.
The environment in SmarTTY will not be affected by running the app from console, however the environment in a SmarTTY session can be different from the environment in the console session and those differences can be causing touchscreen problems.

[support]

Hi,

Are you using a single-machine or a two-machine setup? What directory have you selected to store the kernel cache?
Could you please enable the verbose mode (Tools->Options->VisualKernel), try debugging again and see if the Launcher Output (in the Output window in VS) contains any additional information such as command line that VisualKernel tries to run?

[support]

Hi,

This probably happens because the default session has some environment variables that point Qt to the touch screen. Please try the following to diagnose it:
1. Run your app from an SSH session (e.g. using SmarTTY or open it in VisualGDB). Ensure that the screen is not working.
2. Compare the environment variables in the SSH session and environment variables in the console session (the output of env).
3. Try setting relevant variables in the SSH session. See if this fixes the problem.

Once you figure out the correct variables, please specify them in the VisualGDB Project Properties so that VisualGDB can set them automatically.

[support]

Hi,

Sorry for the late reply. We will be most likely making a new release of SmarTTY within the next 3 months. We will try including most of the suggested features there. Support for multiple servers in one instance, however, may be delayed, as it would require significant changes to the internal architecture.

[support]

Hi,

You could modify the makefile to build/use precompiled headers manually. Add the following lines to it before the FileSpecificTemplates line:

PRECOMPILED_HEADER_FILE := stdafx.h.gch
stdafx.h.gch: $(all_make_files) stdafx.h
$(CXX) $(CXXFLAGS) -c stdafx.h -o stdafx.h.gch -MD -MF $(BINARYDIR)/stdafx.dep

-include $(BINARYDIR)/stdafx.dep

Then modify FileSpecificTemplates this way:

$(BINARYDIR)/%.o : %.cpp $(all_make_files) $(PRECOMPILED_HEADER_FILE) |$(BINARYDIR)
$(CXX) $(CXXFLAGS) -c $< -o $@ -MD -MF $(@:.o=.dep)

Note that this solution will have one major disadvantage: The precompiled header file will be shared between debug/release builds, so you will need to delete it before building the other configuration. You can fix it by creating the gch file inside $(BINARYDIR), but then you will need to add it to the beginning of the include directory list and ensure it is always there before the '.' directory.

[support]

Hi,

Windows 8.1 has several known issues with video drivers. It is unlikely that your issue is related to WinCDEmu. Please try installing Windows 8 instead.

[support]

Hi,

This is caused by a limitation of most SSH servers (they don’t accept more than 10 concurrent channels within one session) and VisualGDB currently does not have a workaround for that.
Normally Visual Studio treats all of your projects as independent ones and tries building them at the same time. Is it intended? If no, please add dependencies between projects so that VS can wait for project A to build before starting to build project B. If yes, please add some arbitrary dependencies to reduce the amount of simultaneously built projects to 5.

[support]

Please use support at sysprogs dot com.

[support]

Hi,

It is always very hard to diagnose such problems without seeing the full GDB log because in most of the cases the root cause is some tiniest difference between different representations of a path. Can you reproduce the problem on a ‘hello, world’ project on the same machine? The only thing we can do is show you the GDB logs on our side demonstrating normal VisualGDB behavior so that you can compare them with yours and search for abnormalities.

Regarding the breakpoint that is shown as unresolved, looks like it corresponds to multiple addresses, but GDB does not report them in a way VisualGDB expects it. Here’s a sample response from setting a breakpoint in a template function that has 2 instances:

^done,bkpt={number="4",type="breakpoint",disp="keep",enabled="y",addr="",times="0",original-location="/tmp/VisualGDB/e/PROJECTS/TEMP/LinuxProject10/LinuxProject10/LinuxProject10.cpp:7"},{number="4.1",enabled="y",addr="0x080486fd",func="f<1>()",file="LinuxProject10.cpp",fullname="/tmp/VisualGDB/e/PROJECTS/TEMP/LinuxProject10/LinuxProject10/LinuxProject10.cpp",line="7"},{number="4.2",enabled="y",addr="0x08048707",func="f<2>()",file="LinuxProject10.cpp",fullname="/tmp/VisualGDB/e/PROJECTS/TEMP/LinuxProject10/LinuxProject10/LinuxProject10.cpp",line="7"}

Your output looks different. Which platform/GDB version are you using?

Regarding path mapping, here’s a sample path mapping that maps /tmp/test to c:something:
[attachment=1:1xtzhfzt]pathmapping.png[/attachment:1xtzhfzt]
Here’s how the /tmp/test/test.h is mapped to c:somethingtest.h:
[attachment=0:1xtzhfzt]sourcelist.png[/attachment:1xtzhfzt]

Does it work for you with exactly the same paths? Do you have any symbolic links involved (e.g. /tmp is mapped to /system/tmp and while you set /tmp, GDB reports it as /system/tmp)?

If a breakpoint shows as resolved but is not hit, does the code at the address reported by GDB match the expected function body (e.g. is it equivalent to the disassembly of your ELF file)? If yes, does placing a manual breakpoint there (asm (“int3”); if you are using GCC) work? Can the memory be write-protected so that GDB fails to set the breakpoint?

Are you running GDB on your target machine or are you using a gdbserver? Are you using a .vgdbsettings file or quick debug?

[support]

Hi,

The sources don’t need to be copied the the debug machine. Does the breakpoint reply contain the address it was resolved to or is it marked as ‘pending’? Can you send us the full GDB log? This will help us diagnose the problem further.
The manual mapping should work with any path prefix (try restarting debug session if it’s not updated immediately). E.g. if you want to map /usr/buildmachineproject/code/somefolder to c:projectcodesomefolder, you need to create the following mapping:

Linux path: /usr/buildmachineproject/code
Windows path: c:projectcode

If this still does not work, please send us the screenshots of your source file mapping window and the window showing incorrectly mapped paths.

[support]

Hi,

Your mapping seems to be set correctly and should work. Please follow the instructions below to diagnose it:
1. In the GDB Session window select ‘all GDB interaction’ so that VisualGDB shows the commands it sends to GDB automatically.
2. Set a breakpoint in a problematic file. VisualGDB will issue a -break-insert command. GDB will report whether it has been resolved.
3. If the breakpoint shows as unresolved, please run the following commands:
* info shared – this will show the loaded shared libraries. Ensure that the library that contains your code is loaded.
* info sources – this will list all source files known to GDB

If your library is not listed in the output of ‘info shared’ it has not been loaded yet, so please ensure it gets loaded and then repeat setting the breakpoint. If the library is shown and has the symbols loaded, but the ‘info sources’ does not list your source file among the source files, there is some problem with your symbols (either GCC is a lot newer or older than GDB or you are missing the -ggdb flag or you are stripping some symbols during build). If the file is shown, please compare the exact path of the file reported by ‘info sources’ with the path that VisualGDB used in the ‘-break-insert’ command. If they don’t match, you need to adjust the path mapping until they match.

[support]

Hi,

By design this should not happen. However in some cases (e.g. MacOS where /tmp is a symbolic link to /private/tmp) the path reported by GDB can be different from the path used to transfer/build files, so VisualGDB won’t detect that it’s mapped.

Does the problem reproduce if you create a new project from scratch? Could you please send us the .vgdbsettings file from that project? Could you also provide us with a GDB log (select ‘all GDB interaction’ in the GDB Session window)?

[support]

Hi,

This looks very strange. Could you please start GDB manually and run the following commands:

b main
run

Will the breakpoint be hit? If yes, please run GDB in MI mode (gdb –interpreter mi ) and run the following commands:

-break-insert main
-exec-run

Will this break in main()? In either case please provide us with the relevant GDB logs so that we could diagnose the problem further.

BTW, are you building a 32-bit version of the app or a 64-bit version? You may need to specify ‘-arch xxx’ in GDB command-line arguments to select the bitness manually.

[support]

Hi,

It’s hard to tell where you got all the malware you are mentioning, but certainly not from the WinCDEmu site. Unlike many other vendors we don’t embed any toolbars or adware in WinCDEmu. WinCDEmu is supported purely through ads on its website and download page. You may have clicked at an ad that linked to some adware; if you believe it’s a malware, please give a link to the site you downloaded it from to Google AdSense support so that they can ban it.

[Author]

Posts