Threaded function cannot call a function with extern "C" but nonthreaded function can
Hello
I have created a dll and so object that shares the same code (note all of this works fine in the dll, it is only when using the so) I have created an initialize function that takes in a bit determining if threading should be enabled When threading is disabled I call some functions that have this added to the beginning: Code:
extern "C" Now, when the bit changes to signify to use threading, my thread starts crashing the program The thread calls the same functions that have been "externed" If I remove the extern "C" from the function, things seem to work ok any suggestions, other then write different functions? I am using CentOS5.4 I am using Codeblocks and glibc version is glibc-2.5-42 I am developing in c/c++ with g++ Thank you |
Hi -
Nonsense - you're jumping to a whole bunch of wrong conclusions here. First: Windows .dll's != Linux .so's. Please don't make *any* assumptions about how Windows .dll's work and expect any of those assumptions to carry forward into how Linux .so's work. Second: "extern's" are a "compile time" thing. They only affect the *names* your compiler uses for global procedures and data; they do *not* affect the structure or values of these procecdures and data. C++ "mangles" function names (to permit "overloading"); C doesn't. Third: I honestly don't believe "threads" vs "not using threads" is the most significant factor here. Having said that: Quote:
1) gdb 2) ldd etc. 'Hope that helps .. PSM |
In looking for any difficult bug, keep in mind the big gap between "bug" and "symptom". In a test where the symptom is seen, you can conclude that the bug "happened". In a test where the symptom is not seen, you cannot conclude that the bug didn't happen.
Maybe the bug clobbers some location in memory it doesn't own. That causes some other section of code to crash. Change something and the crash no longer occurs. Does that mean the bug is no longer clobbering some location it doesn't own? Probably not. Probably it means the owner of that other location isn't crashing. So you have: .so vs. .dll extern "C" vs. ordinary C++ naming threaded vs. non threaded Some or all or none of those factors are involved in whether the bug "happens". Anything at all may be involved in whether a bug that happens has symptoms. So don't try to deduce the nature of the bug by which controllable factors turn the symptom on and off. As paulsm4 suggested, use the debugger to see the direct cause of the symptom and to examine that cause to find the bug. But, you should also be aware of the fundamental differences in load time binding between .dll's and .so's. I don't have that great an understanding myself, so I won't try any exact description here, but in general Unix defaults to leaving many more symbols open to load time binding compared to Windows and Unix does load time binding automatically in more directions compared to Windows. So, for example, you could easily have some call in a .dll that is bound at link time to a function in the same dll, despite the existence of a function of the same name in the .exe. Build that same source code in Linux and the call in the .so file could be load time bound to the function in the main executable, leaving that same named function in the .so unused. Obviously, switching between mangled names and extern "C" names could have significant impact on the set of matching names that could be treated differently by the very different load time binding rules. |
Quote:
I know windows dlls are != linux.so, however g++ should work similar to the visual studio compiler... note the word similar also I understand what extern is... and the function call is what is corrupting the memory, therefore adding extern to the function changes the way the name of the function is stored, therefore causing my dll not to be able to find it. -threads vs non threads is directly related to this issue... I call other functions in a non threaded callback function and they work, it is only when they are called from the threaded function i understand a debugger would be helpful, I would love to use one, unfortunetly I have not been succesful in getting the codeblocks to debug inside of a shared object... I have been outputing data through the console window... when i output the function pointer of the function it does give me a memory address, however it does not reach the first cout inside of the function |
Quote:
Quote:
Quote:
Quote:
|
Quote:
Quote:
Quote:
Quote:
Quote:
I expect other experts here could give you better instructions than I could. Quote:
Quote:
If you need to keep guessing rather than debugging, you might want to also look into whether you are having a stack overflow (which is a decent guess based on everything you said so far). I think you can increase the stack limit with a ulimit command (read the man page). |
Quote:
I know how to f#*$^&D check a function pointer |
Quote:
Quote:
The point you've been making, which I'll reiterate: A symptom is not necessarily the bug. Sometimes the ultimate bug, the bad code you want to change, shows up in program behavior; other times, it may be hidden, but still be lurking and just as incorrect. So if you make a particular change to a misbehaving program (for example, removing threads) and notice that the symptom goes away, that doesn't mean that the actual bug has been removed; it may merely have gone underground, so to speak. So in this example, if removing threads makes the symptom disappear, it does not follow that the actual bug has anything to do with threads. It's up to you, Morty, but if you listen to Mr. John, you'll save your self an amazingly large amount of time in the long run. Just sayin'. |
One approach to something like this is to see how much code you can remove and still reproduce the problem. If you can get it down to a couple of dozen lines or less, post it here to the forum for comment. Sometimes even the process of doing this will help you narrow down the cause.
Also note that there are at least three ways to use libraries in both Windows and Linux. In Windows, there is static linking (of a .lib), dynamic linking (of a .dll), and run-time dynamic linking (ie, using LoadLibrary). In Linux, you have static linking (of a .a), dynamic linking (of a .so), and run-time dynamic linking (ie, using dlopen). When dynamic linking, it is easier to end up with mismatches between the headers used to compile the library and the ones used to compile the main code (especially if the name mangling has been removed using extern "C"!). This can lead to subtle (and not so subtle) stack errors. |
Quote:
Quote:
I read his reply to the first post, I get the point of a symptom and a bug, it is not needed to be repeated, I have seen them before, I will see them again, memory leaks are a b&#*$ to find if they are corrupting memory and you start seeing "symptoms" of them elsewhere... I don't need you to copy and paste text as if I did not read it the first time. I understand the fact that it doesn't make sense for extern and threading to have an issue together, I do not understand all aspects of a shared object as well as I understand a windows dll. That is why I am on this forum, that is why I posted the question, that is why my program crashes I don't appreciate people coming in here, and causing other issues, I did read the symptom vs bug part, as I said in my previous post that was my first assumption. I find it very rude for someone to come into here and tell me that my func point is not a valid test because I don't know how to program without knowing anything on the basis of my programming skills. I don't appreciate people coming in here and telling me that I didn't read what was written the first time. I obviously am going to read and re-read what someone says in a forum that I am the poster, that is the point of this. There are some people in this world that should be on forums to help others, there are others on forums for the thrill of causing issues, I do not appreciate the later, They are rude and are not welcome in the threads that I post. I will assume this topic is now closed, not because the problem is solved, but because of ignorant people |
I just want to clear up one side detail because of the comment by wje_lq
Quote:
Quote:
Obviously, I did not do well at telling morty346 how to get Codeblocks to debug inside a shared object. I didn't even ask specifics about what went wrong when he tried. I appreciate wje_lq's comments on the rest of my attempt to help morty346. |
You come in with incomplete details, no source code and a terrible attitude yet you still expect help?
|
Quote:
But if you will note, I gave a good amount of info in the first post, I assumed there may be other things left out I was not thinking about, no one asked for more information regarding the issue, they seem to understand what I was saying If you read the first response from paulsm4 He told me I was nonsense, and assumed that I assumed shared objects are exactly the same as dll's johnsfine took time out of his day and gave me a decent response in the issues regarding symptoms of a bug, and is assuming the problem lies within that sector of issues I replied to the first post i was simply giving more information in regards to the post and explaining there was no assumption made about dlls second post i again explained there was no assumption made with dlls, it must have been misread or misinterpupted when I wrote it and people were assuming this Then johnsfine decided to turn on the biatch switch he says I ignored his first post, even though i replied to it, and he said i am incompentent and, since I was looking for a solution, not a problem didn't care to listen to him and others reexplain what has already been said but your right smeezy i have a terrible attitude, i gave no relvant info and i should be ashamed of myself for asking for help |
Quote:
|
Quote:
thank you |
All times are GMT -5. The time now is 08:54 AM. |