I am using csv-reading to read from a csv file to convert it into a list.
When I call at the top level, like this
> (call-with-input-file "to-be-asked.csv" csv->list)
I am able to read csv file and convert it into list of lists.
However, if I call the same thing within a function, I am getting the error.
> (read-from-file "to-be-asked.csv")
csv->list: undefined;
cannot reference an identifier before its definition
in module: top-level
I am not getting what's going wrong. I have added (require csv-reading) before the function call.
My read-from-file code is:
(define (read-from-file file-name)
(call-with-input-file file-name csv->list))
EDIT
I am using racket within emacs using Geiser. When I (exit) the buffer and type C-c C-z, it is showing the error.
When I kill the buffer and start the Geiser again, it is working properly.
Is it the mistake of Geiser and emacs?
You've hit the classic problem with what I'll call resident programming environments (I don't know the right word for then). A resident programming environment is one where you talk to a running instance of the language, successively modifying its state.
The problem with these environments is that the state of the running language instance is more-or-less opaque and in particular it can get out of sync with the state you can see in files or buffers. That means that it can become obscure why something is happening and, worse, you can get into states where the results you get from the resident environment are essentially unreproducible later. This matters a lot for things like Jupyter notebooks where people doing scientific work can end up with results which they can't reproduce because the notebook was evaluated out of sequence or some of it was not evaluated at all.
On the other hand, these environments are an enormous joy to use which is why I use them. That outweighs the problems for me: you just have to be careful you can recreate the session and be willing to do so occasionally.
In this case you probably had something like this in the buffer/file:
(require csv-reading)
(define (read-from-file file-name)
(call-with-input-file file-name csv->list))
But you either failed to evaluate the first form at all, or (worse!) you evaluated the forms out of order. If you did this in Common Lisp or any traditional Lisp this would all be fine: evaluating the first form would make the second form work. But Racket decides once and for all what csv->list means (or does not mean) at the point the read-from-file is defined, and a later provide won't fix that. You then end up in the mysterious situation where the function you defined does not work, but if you define a new function which uses csv->list it will work. This is because it has much cleverer semantics than CL, but also semantics not designed for this kind of interactive development as far as I can tell (certainly DrRacket strongly discourages it).
Specifically, my issue is that I have CUDA code that needs <curand_kernel.h> to run. This isn't included by default in NVRTC. Presumably then when creating the program context (i.e. the call to nvrtcCreateProgram), I have to send in the name of the file (curand_kernel.h) and also the source code of curand_kernel.h? I feel like I shouldn't have to do that.
It's hard to tell; I haven't managed to find an example from NVIDIA of someone needing standard CUDA files like this as a source, so I really don't understand what the syntax is. Some issues: curand_kernel.h also has includes... Do I have to do the same for each of these? I am not even sure the NVRTC compiler will even run correctly on curand_kernel.h, because there are some language features it doesn't support, aren't there?
Next: if you've sent in the source code of a header file to nvrtcCreateProgram, do I still have to #include it in the code to be executed / will it cause an error if I do so?
A link to example code that does this or something like it would be appreciated much more than a straightforward answer; I really haven't managed to find any.
You have to send the "filename" and the source of each header separately.
When the preprocessor does its thing, it'll use any #include filenames as a key to find the source for the header, based on the collection that you provide.
I suspect that, in this case, the compiler (driver) doesn't have file system access, so you have to give it the source in much the same way that you would for shader includes in OpenGL.
So:
Include your header's name when calling nvrtcCreateProgram. The compiler will, internally, generate the equivalent of a std::map<string,string> containing the source of each header indexed by the given name.
In your kernel source, use #include "foo.cuh" as usual.
The compiler will use foo.cuh as an index or key into its internal map (created when you called nvrtcCreateProgram), and will retrieve the header source from that collection
Compilation proceeds as normal.
One of the reasons that nvrtc provides only a "subset" of features is that the compiler plays in a somewhat sandboxed environment, without necessarily having all of the supporting tools and utilities lying around that you have with offline compilation. So, you have to manually handle a lot of the stuff that the normal nvcc + (gcc | MSVC| clang) combination provides.
A possible, but non-ideal, solution would be to preprocess the file that you need in your IDE, save the result and then #include that. However, I bet there is a better way to do that. if you just want curand, consider diving into the library and extracting the part you need (blech) or using another GPU-friendly rand implementation. On older CUDA versions, I just generated a big array of random floats on the host, uploaded it to the GPU, and sampled it in the kernels.
This related link may be helpful.
You do not need to load curand_kernel.h yourself and add it to the include "aliases" mechanism.
Instead, you can simply add the CUDA include directory to your (set of) include paths, e.g. by adding --include-path=/usr/local/cuda/include to your NVRTC compiler options.
(I do this in my GPU-kernel-runner test harness, by default, to be on the safe side.)
I am trying to hack into an exe to find the implementation of certain functions and perform actions in an injected dll.
The exe is a sort of screen saver, and fortunately very simple, so it uses important strings to identify code sections.
My dilemma is that one of the functions, 'getaxis', is a virtual function. I know this thanks to the strings window and other telltale info on the string (Audioplayer.Tracklist::GetAxis) that i traced back to an rdata section
.data:01E204B0 off_1E204B0 dd offset aAudioplayer_to ; DATA XREF: _call_vfuncr
.data:01E204B0 ; _call_vfunc+26r
.data:01E204B0 ; "Audioplayer.Tracklist::Internal_GetTrack"
...
Using ida pro i have successfully traced the very function call, but I am unable to find the actual virtual function implementation.
So here's my problem:
1- I am ignorant on the subject, being a newbie in disassembling: is there a way to actually find a virtual function's implementation?
Ida clearly shows the various 'subs' in the "functions window", but there's a couple hundred of functions in there, and i'm hoping there's a better way of finding a virtual functions' declaration.
2- is there any association between a sub name and a virtual function. i was unable to find any.
So how can I find the actual virtual function declaration in disassembled code?
Is this possible at all?
Thanks.
Do you know what compiler/language was used to generate this program? I'm only familiar with how most C++ implementations generate vftables. "Knowing your enemy" is key to reverse engineering.
From the looks of it, those '_call_vfunc' functions may be some sort of implementation detail of some other language's compiler (say some random Pascal compiler, or whatever) which may have a need for retaining such metadata. call_vfunc may throw an error when a pure/nullptr entry is used in whatever they used for a vftable, hence the use of/reference to that string.
If call_vfunc is used to perform ALL virtual function calls, you could hook said function and log the vftable addresses it ends up using. Unless this is an overly complex screen saver, there shouldn't be too many vftables that are used. If IDAPython has any debugger APIs, you could possibly do all the logging via a Python script while debugging with IDA.
Here is my problem:
I have two C++ modules, A and B, which are built as dynamically-linked libraries. A offers basic math functions, and custom exception types. B is a higher level module that uses A.
B::someFunction() calls a function from A, and tries to catch custom exception A:MyExceptionFromA in order to convert it into a custom type B:MyExceptionFromB (since users of module B do not need to know about the implementation details of A).
Everything works fine as long as I remain in the C++ domain. However, if I expose B::someFunction() in python via boost python, the exception is not caught anymore in the C++ module.
I can catch std::runtime_error, from which A:MyExceptionFromA derives, and call typeid(e).name() to get the retrieve the correct mangled name, so I know the correct exception is thrown. Therefore I suspect that the problem comes from resolving this mangled symbol into the correct exception type.
I have found this link, which explains that "python uses [the insular] model to open extension modules, so that extension module writers don't need to know what symbols other extension modules might be using.". I'm suspecting this is part of the problem/solution, but I do not know enough about symbol resolution to figure out how to solve my problem.
Any ideas?
I found a work-around to my problem. Based on this and link text, I figured out that adding
import sys, dl
sys.setdlopenflags(dl.RTLD_NOW|dl.RTLD_GLOBAL)
before my includes solves the problem, by forcing python to open libraries in immediate, global mode. But I'm still hoping for an alternative solution, if there's one. As mentioned in the first link, I'm suspicious that this could have unforeseen effects (I already know that name clashing could be a problem, and I suspect performance can be affected as well, but are there other side effects?)
Everyone (at least everyone who uses a compiled language) has faced compilation errors but how many times do you get to actually crash the compiler?
I've had my fair share of "internal compiler errors" but most went away just by re-compiling. Do you have a (minimal) piece of code that crashes the compiler?
I write the compiler we use, so it crashes sometimes.
easy.
// -*- C++ -*-
template <int n>
class Foo : public Foo<n+1>
{
};
int main(int, char*[])
{
Foo<0> x;
return 0;
};
ejgottl#luna:~/tmp$ g++ -ftemplate-depth-1000000 -Wall foo.cpp -o foo
g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See `<URL:http://gcc.gnu.org/bugs.html>` for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
`<URL:file:///usr/share/doc/gcc-4.2/README.Bugs>`.
I haven't made GHC (a Haskell compiler) crash yet, but I've gotten it to error out with a
My brain just exploded.
I can't handle pattern bindings for existentially-quantified constructors.
It's pretty easy to work around, and you don't hit this unless you have some tricky (and usually wrong) design, but it probably wins as the best compiler error message ever.
VC catches it gracefully now, but in the mid 90's, this would crashed both Microsoft C++ and Borland C++ compilers:
struct MyClass
{
MyClass operator->() { return *this; }
};
int main(int argc, char* argv[])
{
MyClass A;
A->x;
}
An overloaded operator-> is intrinsically recursive. The function is expected to return a pointer, which oper-> is again applied to. This fragment made code generation infinitely recursive.
Actionscript 3.0:
switch(on_some_variable)
{
}
Empty switch = Kaboom!
Visual C++ 9.0 SP1
this just happened to me
------ Build started: Project: pdfp, Configuration: Debug Win32 ------
Compiling...
reader.cpp
xref.cpp
c:\projects\pdfp\xref.cpp(52) : fatal error C1001: An internal error has occurred in the compiler.
(compiler file 'f:\dd\vctools\compiler\cxxfe\sl\p1\c\toil.c', line 8569)
To work around this problem, try simplifying or changing the program near the locations listed above.
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
Generating Code...
Build log was saved at "file://c:\Projects\pdfp\Debug\BuildLog.htm"
pdfp - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Well, this didn't actually crash the compiler -- It was merely a bug were VC++ wouldn't accept perfectly good code. (details provided here).
The odd this about it was that it was only triggered when three fairly obscure conditions were all met. Moving one line of code was all that was needed for an effective workaround. And one of the needed pre-conditions was "using namespace std;" which is widely discouraged in production code.
Nevertheless, messages asking how to fix the problem were a staple on Microsoft VC++ newsgroups. I couldn't figure out how so many people stumbled onto an obscure bug. So, eventually, I asked someone.....
The exact code needed to trigger the bug was an example in Stroustrup's "The C++ Programming Langauge". (*)
(*) Note, I'm not saying he did it on purpose. I sure he tested it under a UNIX variant of C++, and was completely unaware of it's affect on VC++.
I've seen a few compiler bugs in the C# compiler (all edge cases, all reported appropriately) and confirmed some crashes provoked by other people.
The scariest compiler (of a sort) bug I've encountered was a JIT bug in one version of Java. It was quite reproducible, but caused the VM to go down. Adding a fairly no-op statement (I can't remember exactly what offhand - possibly just declaring an extra local variable with an initial value) moved it away from whatever corner case it happened to be - and it was fixed in a later version.
This crashed the C64 BASIC:
PRINT 0 + "" +- 0
Yes, especially when it's an old or undermaintained compiler (GCC 2.95, Tendra in C++ mode). I don't keep the pieces of code around, though.
Visual C++ 5. 'Nuff said.
Oops, forgot an 'e' in typedef and crashed the compiler.
typdef struct kGUIColor GameColor;
c:\source\kgui\samples\space\space.cpp(35) : fatal error C1001: INTERNAL COMPILER ERROR
(compiler file 'msc1.cpp', line 2708)
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
Today VS2003SP1 gave me a C1001 (Internal Compiler Error) complaining about compiler file 'msc1.cpp', line 2708) because of this:
struct PATTERN {
…
};
It turns out that the problem was that the structure name I was trying to define (PATTERN) was already a typedef in the GDI for a brush type. However instead of telling me that the symbol is already defined (like it does for most other things) it not only did not point to the structure as the problem—I narrowed the problem down to it by selectively commenting out blocks until the error went away—but it also gave me the aforementioned cryptic error which has nothing to do with the file specified—which I can’t even find to examine the line in question. :|
I was able to reproduce it with the following code:
typedef int SOMETHINGOROTHER;
struct SOMETHINGOROTHER {};
> fatal error C1001: INTERNAL COMPILER ERROR
> (compiler file 'msc1.cpp', line 2708) …
Whereas the following code gives the expected error message:
struct SOMETHINGOROTHER {};
typedef int SOMETHINGOROTHER;
> 'SOMETHINGOROTHER' : redefinition; different basic types
Clearly the problem is in the compiler’s structure handling routine.
I wonder if VS2005+ do better…
Here's a way to crash the VS2003 C++ compiler.
typedef map<int,int> Tmap;
private: Tmap; * m_map;
This will result in a crash and the following error message
fatal error C1001: INTERNAL COMPILER
ERROR (compiler file 'msc1.cpp', line
2708) Please choose the Technical
Support command on the Visual C++ Help
menu, or open the Technical Support
help file for more information
Remove the semicolon immediately after Tmap (second line which defines m_map) to eliminate the error.
In a project I was working in, some specific usages of Boost Lambda expressions could make the Visual C++ compiler crash. (We were using Visual Studio 2003)
The compiler would only crash during the release build, a debug build would work fine.
There had been a religious war raging through the team about the appropriate usage of the lambda libraries, I was almost grateful that the compiler settled it for us. :-)
In version 1.2.x of the Mono C# compiler would crash quite a bit with complicated code (if I remember correctly, nested anonymous delegates). Fortunately with 2.x release, I haven't seen any crashes.
At my previous job we had a simulator which was notorious for being able to crash (ICE) compilers or cause them to generate incorrect code. And when the code actually was generated correctly, ofter the compiler took 15 minutes for a single source file. Visual Studio was never (as long as I worked there) able to compile the simulator core.
The core was automatically generated from a DSL, and the generated code often pushed the compiler to its limits.
Upgrading to a new version of GCC often caused widespread nervosity: will the new version work?
Thanks to #Nick, this crashes VS2005.
template<typename Res, typename T>
Res operator_cast(const T& t)
{
return t.operator Res();
}
int main()
{
return operator_cast<int>(0);
}
I've crashed a compiler before by running it out of memory.
Give a DOS compiler about 0.5mb of source code. Crunch.
When you get a message "Catastrophic Failure" you know you're trying....
Michael
I use both pcc and gcc to compile my old OS project.
I found a bug with how both pcc and gcc handle a non-trivial piece of code and it crashed pcc.
(chars are signed on my platform)
struct{
char myvalue:1;
}mystruct;
pcc crashed because all bitfield values must be int though, so it's really more buggy there, but gcc handles it wrongly. See, if you think about it, it is signed, but only has room for one bit. So therefore, it only can store 0 and -1. Well, gcc handles it wrong by storing 0 or 1.
VC++ has crashed on me when compiling C++ if template usage is messed up (e.g., missing out on a closing ">").
I did. Some Delphi versions (lets say #4) crashed very often with cryptic error messages.
The newer versions (2006 and more) are stable but not rock solid. (7 was great in that case).
Compiler crashes often occur with large edits, and debug sessions of complex projects (lots of dll's). Most of the time a restart of the ide is enough. But sometimes you need to restart the PC.
O and I once crashed OS2 along with the compiler because the swapfile grew too large.
One time when I used the generators example from the Python docs, it broke the version of Python we were using. The same week, one of my colleagues managed to misuse the FFI such that any calculation involving the number 3 would crash python.
The Microsoft Xbox 360 compiler can crash easily. I was given source code with Japanese comments and when converted to regular text one of the last characters on the line was a '\' so it continued the comment onto the next line. If the next line was a switch command, then the compiler crashes.
//wierd japanese characters here %^$$\
switch(n)
{
case 0:
.....
break;
case 1:
.....
break;
}
I have crashed Delphi 7 many times asking it to compile legacy dos code.
The prime culprit seems to be any qualification of something as being in the system unit. This won't always blow it up but when it blows up on such stuff I look through and rewrite anything that requires such an override and the problem goes away.
The blowups are 100% reproduceable but I have never managed to make a simple test case. It doesn't actually crash the compiler most of the time, you usually get an error that has nothing to do with the problem and may be hundreds of lines from it. The environment is destabilized, save and exit is ok but don't think of doing anything else.
Back in the stone age with Borland Pascal 7 (the last dos version) I broke it many times. No crash, just incorrect and inconsistent code emission. I finally learned to keep the .EXE (not counting debug info) below 3mb. The farther beyond that I went the more unstable it got.
I've crashed VC++ a number of times, usually with template code. But that's not the most interesting crash...
I crashed the VS2005 Team System compiler with the /analyze option compiling my shared code library which compiled without error without the switch, and on VS2008 with and without the switch. Of course MS wasn't very interested because it was a bug in the old version of the compiler, but I thought it was pretty interesting.
I managed to segfault the Python interpreter. Of course, I was working on a C extension at the time and getting it not-quite-right.
It doesn't happen as much as it used to, but occasionally the ASP.net precompiler has issues - I haven't seen it personally, but I have fixed a problem on another project once where they had name clashes because they weren't using namespaces properly (caused compiler crashes) during pre-compile.
In the good old days (unmanaged MSVC++) we had the odd compiler crash usually due to linking in external static win32 classes (.lib) and a couple of odd bits of code occasionally caused issues, but these were all picked up very quickly.
I don't know if I would call it crashing, but sdcc (Small Device C Compiler) fails at compiling code formed in a particular way:
Target: 8051
Code had to execute in a 512 byte cache loaded from an external tester
Tester is in control and stores the code - cache can't fetch the next page
No function calls allowed - the PC (program counter) would skip to a place not resident in cache; preprocessor macros were used to accomplish modular coding practice
Jumps (branching) allowed if it doesn't skip out of the cache
No const values - in the data section of the program code which causes code in cache to fetch something not in cache - preprocessor constant (#define) OK here
The preprocessor macros are unrolled resulting in flat, but large code - everything in main(); execution skips the startup code (setting up the stack, etc) and starts at the beginning of main()
Relevant part of this answer:
Occasionally, sdcc would refuse to compile syntactically correct code, with a message about running out of memory. This even happened compiling on 64-bit boxes with 8GB of RAM.
The solution in these cases was to split the firmware into separate pieces and compile them separately and execute them separately. The pieces may have been able to be linked back together, but at that point it didn't matter.
I didn't try it, but the Keil 8051 compiler probably could have handled the problematic code.