I'm having trouble with IMAGE_EXPORT_DIRECTORY values, whenever I'm calculating address of it, it gives me wrong values (like Name, NumberOfNames, AddressOfNames, etc..).
I'm calculating it by the following code.
IMAGE_EXPORT_DIRECTORY *export_directory = (IMAGE_EXPORT_DIRECTORY*)(nt_headers->OptionalHeader.DataDirectory[0].VirtualAddress + (DWORD)dos_header);
Following in debugger, the address is right, there must be a IMAGE_EXPORT_DIRECTORY, but why it gives me wrong results? Can't access any of the elements from it, because it says bad ptr..
Tried and works fine with kernel32.dll, but fails on user32.dll when extracting names from AddressOfNames.
Using Windows 8 x86.
Related
When attempting to print out a custom hash map variable named "table" I seem to get this error with lldb:
error: expression failed to parse:
error: <lldb wrapper prefix>:45:31: no member named 'table' in namespace '$__lldb_local_vars'
using $__lldb_local_vars::table;
~~~~~~~~~~~~~~~~~~~~^
error: <user expression 2>:1:1: use of undeclared identifier 'table'
YES the variable is declared in this scope and in fact when switching to my laptop I can use LLDB just fine and print out the table contents.
I also notice other issues when printing out a different vector. It is clearly populated when adding print statements however when using lldb to print out the vector it shows it as unpopulated and all of size 0.
I am running Fedora 35 and I have tried updating and reinstalling lldb. As I said before, my laptop is able to print everything out just fine.
I have also tried following this post:
LLDB gives "use of undeclared identifier" error for local variable
using image lookup -va $pc yields the following results indicating that the table is present:
Variable: id = {0x00018088}, name = "table", type = "HashTable &", location = DW_OP_fbreg -904, decl = main.cpp:113:24
I can share the chunk of code giving me problems but I am not sure it is relevant. I simply pass this variable into the function by reference and print it. I can print it no where else in the program.
Note:
This extends beyond printing, I cannot access the size, capacity, or anything else relating to the 'table' variable. LLDB just throws this error.
Also perhaps on an unrelated note I noticed a few weeks ago that clearly deleted objects were still showing up and printable in LLDB. I could still access the variable and manipulate the data and what not but it was very clearly deleted. Again perhaps unrelated I suspected it was just that LLDB hadn't updated the variable list or something of this nature but it cost me a bit of time figuring out why the variable wasn't deleted.
Thanks for any help in advance
EDIIT:
Compiling with clang++ seems to fix my issue on my desktop? I could just use clang instead of g++ but I still am curious how this difference in compilers changes it? I suppose I understand it fundamentally but using g++ and lldb works without issue on my laptop. Is using lldb and g++ together a big no no?
(I must use lldb on my laptop as it is an M1 and only supports lldb I believe so I just opted to use lldb on my desktop as well)
I've been having an issue with a certain function call in the
dphaseWeighted = af::convolve(dphaseWeighted, m_slowTimeFilter);
which seem to produce nothing but nan's.
The back ground is we have recently switched from using AF OpenCL to AF Cuda and the problem that we are seeing happens in the function.
dphaseWeighted = af::convolve(dphaseWeighted, m_slowTimeFilter);
This seems to work well when using OpenCL.
Unfortunatley, I can't give you the whole function because of IP. only a couple of snippets.
This convolve lies deep with in a phase extract piece of code. and is actualy the second part of that code which uses the af::convolve funtion.
The first function seems to behave as expected, with sensible floating point data out.
but then when it comes to the second function all I'm seeing is nan's coming out ( I view that with af_print amd dumping the data to a file.
in the CMakeList I include
include_directories(${ArrayFire_INCLUDE_DIRS})
and
target_link_libraries(DASPhaseInternalLib ${ArrayFire_CUDA_LIBRARIES})
and it builds as expected.
Has anyone experience any think like this before?
When I run the code in windows, it works as expected. But when I run it in linux, the program doesn't run as expected and produces a completely different output.
I'm assuming its a problem in the all_unique_letters method, but I can't seem to figure it out.
In bool all_unique_letters(const string &s), unsigned int v; is used without being initialized. If it contains something else that 0, the function reports a letter as a duplicate when it is not.
I tried this because I want to learn how to grab a machine unique ID.
I need it because I'm gonna code a program that reads the machineid and compares it to a specific one.
I edited the code(in the end, the code that prints the Machine ID) to this:
string MachineID;
MachineID = vtProp.bstrVal;
if (MachineID == vtProp.bstr)
but it only gives me this error.
How would I make my HWID variable be set to the value of vtProp.bstrVal, then compare it with vtProp.bstrVal? I've googled for some hour now, can't seem to get it fixed.
Thanks in advance!
Simple syntax error - you've used =, which is assignment, instead of ==, which is comparison.
Because c++ accepts nonboolean types in if statements, the code if(variable = value) is acceptable to the compiler, which tries to assign MachineID the value of vtProp.bstr, which causes your error due to type mismatch.
im having issues with MySQL++ and desperately need help.
I'm using Visual Studio 2010, MySQL++ v3.1.0 and MySQL v5.1.59( x86 & x64 );
All Library's have been compiled correctly. This error only occurs in Debug version due to the compiler setting "Both (/RTC1, equiv. to /RTCsu) (/RTC1)" being on.
Edit: I should note that this only happens in Debug version. In Release it works like a charm
I've tracked the problem back to the mysqlpp_d.dll, the MySQL++ object are crashing on there destructors due to reference counting. It complains about not being capable of accessing the memory of the ref counter, and when it tries to decrease it, it crashes. At least thats what I think happens.
I tried this to make sure everything gets derefrenced and removed in the correct order (even tho its irrelevant, but helped me track the true problem down I hope): http://pastebin.com/Ru0uYcy9
It crashes with:
First-chance exception at 0x000007feeef5dd4c (mysqlpp_d.dll) in Launcher.exe: 0xC0000005: Access violation writing location 0x000007feeeff5148.
Unhandled exception at 0x000007feeef5dd4c (mysqlpp_d.dll) in Launcher.exe: 0xC0000005: Access violation writing location 0x000007feeeff5148.
And breakes here:
http://pastebin.com/9Mfr7NwB
This code has a serious bug:
mysqlpp::UseQueryResult res;
{
mysqlpp::Query query = conn.query();
query << "SELECT USER();";
res = query.use();
row = res.fetch_row();
}
You aren't consuming all the result sets. In MySQL, stored procedures that return data return at least two separate result sets: the first is the results you asked for, and the second is status information about the call itself. See examples/multiquery.cpp in the MySQL++ source distribution for the correct way to handle this. Also see section 3.16 in the MySQL++ user manual.
The main consequence of this is that later queries on the same connection will fail.
I think your memory corruption is actually a secondary effect, and that the primary problem stems from ignoring the MySQL C API's attempts to tell you that you're trying to run two overlapping queries on the same connection, because you didn't consume the entire first result set. From what little code you've posted, I can see that you're ignoring returned error codes, so if you've also disabled MySQL++ exceptions, your code will completely ignore this error and blithely go on to stomp all over things it shouldn't.
By the way, please lose the trailing semicolon on the query. It isn't needed with the C API, and can cause confusion, especially in the face of multi-queries. Use semicolons only to separate multiple statements in a single query.