In RStudio there's a Tools menu which allows you to select an installed version/architecture of R under Global Options.
That's great, but my issue with that is that, as the name implies, it is a Global option, so once you select a different architecture (or version number) you then have to restart RStudio and it applies to all of your RStudio instances and projects.
This is a problem for me because:
I have some scripts within a given project that strictly require 32-bit R due to the fact that they're interfacing with 32-bit databases, such as Hortonworks' Hadoop
I have other scripts within the same project which strictly require 64-bit R, due to (a) availability of certain packages and (b) memory limits being prohibitively small in 32-bit R on my OS
which we can call "Issue #1" and it's also a problem because I have certain projects which require a specific architecture, though all the scripts within the project use the same architecture (which should theoretically be an easier to solve problem that we can call "Issue #2").
If we can solve Issue #1 then Issue #2 is solved as well. If we can solve Issue #2 I'll still be better off, even if Issue #1 is unsolved.
I'm basically asking if anyone has a hack, work-around, or better workflow to address this need for frequently switching architectures and/or needing to run different architectures in different R/RStudio sessions simultaneously for different projects on a regular basis.
I know that this functionality would probably represent a feature request for RStudio and if this question is not appropriate for StackOverflow for that reason then let me know and I'll delete it. I just figured that a lot of other people probably have this issue, so maybe someone has found a work-around/hack?
There's no simple way to do this, but there are some workarounds. One you might consider is launching the correct bit-flavor of R from the current bit-flavor of R via system2 invoking Rscript.exe, e.g. (untested code):
source32 <- function(file) {
system2("C:\\Program Files\\R\\R-3.1.0\\bin\\i386\\Rscript.exe", normalizePath(file))
}
...
# Run a 64 bit script
source("my64.R")
# Run a 32 bit script
source32("my32.R")
Of course that doesn't really give you a 32 bit interactive session so much as the ability to run code as 32 bit.
One other tip: If you hold down CTRL while launching RStudio, you can pick the R flavor and bitness to launch on startup. This will save you some time if you're switching a lot.
I'm writing plugin for the MITK framework using Qt-Creator with gdb on Linux-Mint 15.
Resuming after halting at any breakpoint doesn't work, or seems to take upwards of 30 minutes (every time). My project is not very big however, so there's no way I've got the debugger set up correctly.
I've got the Qt 4.8 and 5.01 packages installed. MITK requires Qt4 and I believe to have it specified everywhere in the makefiles.
I do get the following output when starting to debug:
&"warning: GDB: Failed to set controlling terminal: Unpassender IOCTL (I/O-Control) f\303\274r das Ger\303\244t\n"
no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
From other answers on this site I get that the first line can be ignored...
Can anyone say if the second line is related to my problem and possibly how?
I wonder if this could have to do with there being two versions of Qt installed on my pc - I dont know how to get Qt5 completely off the system with all its packages though...
One user mentioned this: https://stackoverflow.com/a/17256365/2561709
Its all I could really find but I dont understand it, any clues?
I'd appreciate any hint at a possible cause of the problem. Please tell me what other relevant information I could provide, thanks!
I'm trying to simulate my VHDL code using Xilinx ISim.
When I try to generate the testbench for the simulation, the simulator throws up the following error:
FATAL_ERROR:Simulator:Fuse.cpp:500:1.133 - Failed to compile generated C file isim/
I tried to simulate it on an 32-bit Ubuntu 12.04 using ISE 14.3, a 32-bit Windows XP SP3 also ISE 14.3 and a 64-bit Windows 7 SP1 same ISE version as before.
The Xilinx support provided a reinstall as solution, but that didn't solve the problem.
Maybe the community on Stack Overflow has an idea?
That is a tool crash and it's going to be hard to get an answer here on stackoverflow, at least without providing some code and the steps that cause the problem. I would get back with Xilinx support and open a case -- this is something they need to fix in the tool. Can you provide your code as a testcase to them? Potentially cutting it down so it's as simple as possible while still causing the problem.
I can never provide production code to EDA vendors as a testcase due to confidentiality. Quite often I find that while creating a smaller testcase that I can send that I'm able to also find a workaround to the original problem. Try a binary search procedure -- remove or black box half of your design and see if the crash still happens.
And -- can you find the particular C file that fails to compile? Looking at it may give a clue as to what in your design may be causing the problem.
I've recently had a horrible problem with QTCreator. After the first time of running the program, ALL debugging instances segfault upon constructing the MainWindow object. Even if i make a blank QTwidget project and run in debug (without editing a single bloody thing), i get a segfault.
This persists after dozens of reinstalls. I have tried both the SDK as well as the IDE and library seperately. The version of the library is irrelevant, i always get the seg fault and its only on my tower. My laptops work just fine.
Does anyone have any possible solutions? Any help will be appreciated.
I needed to run QtCreator in admin mode in order for GDB to function properly.
Without knowing more (please answer to cbamber85's comment), such issues are known to be caused by uberprotectious anti-virus solutions or other software that hooks into places where GDB would usually hook in (Vendor OS-'enhancement' tools are infamous for doing that). This is a known Problem with GDB.
You could try to disable your virus scanner or remove/unload/remove from autostart the vendor tools and try again.
If that doesn't work, the content of the debugger output log pane (Windows > Views > Debugger Log) would be interesting.
Sorry, I couldn't figure out a good way to phrase my real question.
I run a high-traffic ASP.NET site on a 64-bit machine. I have IIS running in 32-bit mode, however, due to some legacy components of the app. I am running this particular web app inside an application pool that has the web garden option on (running 6 processes inside an 8 core machine).
Once or twice a week one of the processes will skyrocket into 100% CPU utilization, causing a giant slowdown for the site, so my plan was to wait until that happens, memory dump the offending process, then poke around WinDbg to zero in on the thread that's spiking to see where the code is spinning its wheels.
I've debugged using WinDbg before to figure out what was causing a deadlock on the site, but that was several months ago and I can't remember how I got it working. (As a side note, this is a lesson to document everything you do.)
I'm running WinDbg on the Windows 2003 server that's running the site, so as to prevent any DLL version problems. Here have been my steps so far, please let me know where I'm going wrong to get the error message that I'm getting.
I first memory dump the spiking process using UserDump, with the following command, where 3389 is the ID of the process:
userdump -k 3389
I load the dump into the x86 edition of WinDbg.
Since I'm running 32-bit on a 64-bit machine, I first load the memory dump and then:
.load wow64exts
.effmach x86
I make sure that my symbol path includes the directory that contains my apps PDB files:
.sympath+ c:\inetpub\myapp\bin
Running just `.load SOS' fails with an error of "The system cannot find the file specified", so I go the fully qualified route of the following, which works:
.load c:\windows\microsoft.net\framework\v2.0.50727\sos
From here, I'm lost. I try any of the SOS commands, like !threads, only to get this error:
Failed to load data access DLL, 0x80004005
That error is also accompanied by the numbered list of items that I should be verifying.
I have verified that I am running the most current version of the debugger, mscordacwks.dll is in fact in the same directory as the mscorwks.dll file, and I'm debugging on the same architecture as the dump file.
I've also run the magical ".cordll -ve -u -l" command, but that doesn't solve anything. I'm always greeted with "CLR DLL status: No load attempts" when I execute that. Then I try ".reload", which yields a handful of warnings like "WARNING: wldap32 overlaps dnsapi". I wish it said something like "CLRDLL: Loaded DLL C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscordacwks.dll". But it doesn't.
Try executing !sw before running the sos commands. See this blog post.
(MSDN) How To: Use CLR Profiler
(MSDN Magazine) Investigating Memory Issues
In my experience, spiking app pool can be due to it being recycled. Have you tried IIS Crash / Hang agent and IIS Dump ?
http://www.microsoft.com/downloads/details.aspx?FamilyID=01c4f89d-cc68-42ba-98d2-0c580437efcf&DisplayLang=en
Also included with them is a dumpfile analyzer which will tell you about memory leaks and even suggest areas of your code that need fixing (complete with links to the applicable MSKB articles!)
Dude - not sure if this helps, but maybe try this.
Copy c:\windows\microsoft.net\framework\v2.0.50727\sos.dll to the same directory where windbg is installed to (eg. c:\program files\Debugging Tools for Windows\ ). Why? make it easy to load the sos file
run windbg
load the memory dump file. for me, i use ctrl-D or File -> open crash dump
.load sos <-- take note of the fullstop BEFORE the load command
.symfix c:\temp\debug_symbols
.reload
Ok.. take note of the commandline. this tells me the current THREAD that the dump was in. That might be useless for a HIGH CPU scenario .. because we could be in any thread.
so from here i look at the threads that were running and check out the busiest thread
8 !threadpool <-- this is so i can see the cpu utilization to check we are in a crap (busy) state... eg 100% cpu or what not.
9 !runaway <-- list the threads that have ben around the longest...
eg.
0:027 !runaway
User Mode Time
Thread Time
18:704 0 days 0:00:17.843 <-- Thread #18
19:9f4 0 days 0:00:13.328 <-- Thread #19
16:1948 0 days 0:00:10.718
26:a7c 0 days 0:00:01.375
24:114 0 days 0:00:01.093
27:d54 0 days 0:00:00.390
28:1b70 0 days 0:00:00.328
0:b7c 0 days 0:00:00.171
25:3f8 0 days 0:00:00.000
23:1968 0 days 0:00:00.000
thread 18 and 19 have been hanging around awhile.. hmm.... are they stuck in a loop?
~18s <-- goto thread 18.
!clrstack <-- clr call stack .. which is just like debugging in windows.
.. and from here u can dump objects and stuff by giving the address references and stuff.
check out !help to list some commands to try and use .. i think !help.sos also works?
HTH .. if u still get stuck, ask away at what worked and what didn't.
I just had to deal with a similar problem. In my case, it turned out that WinDbg wasn't able to find the correct version of mscorwks.dll. In addition to the Framework version, there is also a revision of the DLL which can be different between the same framework version.
In theory, the Microsoft symbol servers should be able to supply the necessary DLL, but it wasn't happening for me. To solve it, I used !sym noisy to get additional information on symbol loading. When I did !dumpstack, I got the error message:
SYMSRV: http://msdl.microsoft.com/download/symbols/mscorwks.dll/492B82C1590000/mscorwks.dll not found
To fix this, I created the appropriate folders in my local symbol cache, and copied mscorwks.dll from the machine the dump came from. After a .reload, WinDbg found the necessary DLL in the local symbol cache, and continued on happily.
Alternatively, you can find the exact version of mscorwks being used with lm v m mscorwks. You can then find the update that contains the version you need from this list. You will need to extract the necessary DLLs from the particular update to the right location.