LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices


Reply
  Search this Thread
Old 01-11-2010, 07:43 AM   #1
morty346
Member
 
Registered: Feb 2009
Posts: 52

Rep: Reputation: 15
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"
everything works fine

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
 
Old 01-11-2010, 08:03 AM   #2
paulsm4
LQ Guru
 
Registered: Mar 2004
Distribution: SusE 8.2
Posts: 5,863
Blog Entries: 1

Rep: Reputation: Disabled
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:
Q: exactly *where* the crash is occurring?
Tools that might be helpful include:

1) gdb
2) ldd
etc.

'Hope that helps .. PSM

Last edited by paulsm4; 01-11-2010 at 08:05 AM.
 
1 members found this post helpful.
Old 01-11-2010, 08:56 AM   #3
johnsfine
LQ Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,286

Rep: Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197
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.
 
1 members found this post helpful.
Old 01-11-2010, 09:04 AM   #4
morty346
Member
 
Registered: Feb 2009
Posts: 52

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by paulsm4 View Post
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:



Tools that might be helpful include:

1) gdb
2) ldd
etc.

'Hope that helps .. PSM

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
 
Old 01-11-2010, 09:12 AM   #5
morty346
Member
 
Registered: Feb 2009
Posts: 52

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by johnsfine View Post
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.

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.
See other post for reponse...







Quote:
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.
I also first assumed it was something with the memory, however it seems to happen to any externed function in any area... it seems very consistent in the fact that it has to do with threading and using extern, (this has been tested extiensvely -> therefore why i have come to a forum to ask the question)

Quote:
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.
windows aside, the point that it works in linux without threading is my concern, i don't truly care about the differences between a .so and a dll, because without threading it works fine in a .so, and with threading it doesn't

Quote:
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.
Correct, and this is why I am asking on a forum, because I do not see the relation between threading and name mangaling...
 
Old 01-11-2010, 09:55 AM   #6
johnsfine
LQ Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,286

Rep: Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197
Quote:
Originally Posted by morty346 View Post
the function call is what is corrupting the memory
I don't think you could really know that.

Quote:
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.
That doesn't sound consistent with the other things you have said.

Quote:
threads vs non threads is directly related to this issue.
I don't think you could really know that.

Quote:
I call other functions in a non threaded callback function and they work, it is only when they are called from the threaded function
You appear to be ignoring everything I said about bug vs. symptom.

Quote:
I have not been succesful in getting the codeblocks to debug inside of a shared object.
I'm not an expert in gdb nor in codeblocks (though I use both). In almost any debugger in Windows or in Linux, there are some complications in debugging inside shared objects. But it is something you should learn how to do.

I expect other experts here could give you better instructions than I could.

Quote:
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
There are many ways a beginner can be confused by debugging with cout. So I would not be confident of the conclusions you reached from that test.

Quote:
Originally Posted by morty346 View Post
I am asking on a forum, because I do not see the relation between threading and name mangaling...
We don't see that relation either. That is why I am estimating (and Paulsm4 also seems to be estimating) that thread vs. non thread is not a direct part of the bug, but something indirectly affecting whether the bug has a symptom.

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).

Last edited by johnsfine; 01-11-2010 at 10:01 AM.
 
1 members found this post helpful.
Old 01-11-2010, 10:02 AM   #7
morty346
Member
 
Registered: Feb 2009
Posts: 52

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by johnsfine View Post
I don't think you could really know that.



That doesn't sound consistent with the other things you have said.



I don't think you could really know that.



You appear to be ignoring everything I said about bug vs. symptom.



I'm not an expert in gdb nor in codeblocks (though I use both). In almost any debugger in Windows or in Linux, there are some complications in debugging inside shared objects. But it is something you should learn how to do.

I expect other experts here could give you better instructions than I could.



There are many ways a beginner can be confused by debugging with cout. So I would not be confident of the conclusions you reached from that test.



We don't see that relation either. That is why I am estimating (and Paulsm4 also seems to be estimating) that thread vs. non thread is not a direct part of the bug, but something indirectly affecting whether the bug has a symptom.
Mr. John do not respond to this thread, your help is not welcomed, I do not need someone to belittle me when I am trying to solve an issue, I have been a programming for many years, do not insult my intelligence.

I know how to f#*$^&D check a function pointer

Last edited by morty346; 01-11-2010 at 10:04 AM.
 
0 members found this post helpful.
Old 01-11-2010, 09:51 PM   #8
wje_lq
Member
 
Registered: Sep 2007
Location: Mariposa
Distribution: FreeBSD,Debian wheezy
Posts: 811

Rep: Reputation: 179Reputation: 179
Quote:
Originally Posted by morty346 View Post
Mr. John do not respond to this thread, your help is not welcomed
His help in this thread is certainly welcomed by me. He spends a lot of time with helpful points that I now won't have to raise.
Quote:
Originally Posted by johnsfine View Post
I expect other experts here could give you better instructions than I could.
Actually, John, you did quite well.

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'.
 
1 members found this post helpful.
Old 01-12-2010, 12:38 AM   #9
neonsignal
Senior Member
 
Registered: Jan 2005
Location: Melbourne, Australia
Distribution: Debian Bookworm (Fluxbox WM)
Posts: 1,391
Blog Entries: 54

Rep: Reputation: 360Reputation: 360Reputation: 360Reputation: 360
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.

Last edited by neonsignal; 01-12-2010 at 01:05 AM.
 
2 members found this post helpful.
Old 01-12-2010, 07:12 AM   #10
morty346
Member
 
Registered: Feb 2009
Posts: 52

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by wje_lq View Post
His help in this thread is certainly welcomed by me. He spends a lot of time with helpful points that I now won't have to raise.
w/e not the point of the thread, don't need people like him causing issue in a thread, when I am mearly asking for help

Quote:
Actually, John, you did quite well.

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'.
I agree, he made some valid points in his first post, and I thank him for that,
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
 
Old 01-12-2010, 09:23 AM   #11
johnsfine
LQ Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,286

Rep: Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197Reputation: 1197
I just want to clear up one side detail because of the comment by wje_lq

Quote:
Originally Posted by johnsfine View Post
In almost any debugger in Windows or in Linux, there are some complications in debugging inside shared objects. But it is something you should learn how to do.

I expect other experts here could give you better instructions than I could.
Quote:
Originally Posted by wje_lq View Post
Actually, John, you did quite well.
My "other experts" statement was only in reference to "debugging inside shared objects".

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.
 
Old 01-12-2010, 12:33 PM   #12
smeezekitty
Senior Member
 
Registered: Sep 2009
Location: Washington U.S.
Distribution: M$ Windows / Debian / Ubuntu / DSL / many others
Posts: 2,339

Rep: Reputation: 231Reputation: 231Reputation: 231
You come in with incomplete details, no source code and a terrible attitude yet you still expect help?
 
0 members found this post helpful.
Old 01-12-2010, 12:58 PM   #13
morty346
Member
 
Registered: Feb 2009
Posts: 52

Original Poster
Rep: Reputation: 15
Thumbs up

Quote:
Originally Posted by smeezekitty View Post
You come in with incomplete details, no source code and a terrible attitude yet you still expect help?
I am not going to waste my time with this, so I am not going to into detail...

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
 
Old 01-12-2010, 01:54 PM   #14
wje_lq
Member
 
Registered: Sep 2007
Location: Mariposa
Distribution: FreeBSD,Debian wheezy
Posts: 811

Rep: Reputation: 179Reputation: 179
Quote:
Originally Posted by morty346 View Post
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
Ok, at this point a moderator needs to come along and throw us all in the pokey until we sober up.
 
Old 01-12-2010, 02:07 PM   #15
pixellany
LQ Veteran
 
Registered: Nov 2005
Location: Annapolis, MD
Distribution: Mint
Posts: 17,809

Rep: Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743
Quote:
Originally Posted by wje_lq View Post
Ok, at this point a moderator needs to come along and throw us all in the pokey until we sober up.
And here I am---Now, will everyone please chill....any more posts to this thread need to be only on the substance of whatever the question was/is.

thank you
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Extern "c" declaration for a function is giving error. manas_sem Programming 3 06-28-2007 12:15 PM
I need help on this PHP error -- "Call to undefined function: mysql_connect()" yzh999 Linux - Software 1 08-12-2006 03:14 AM
GD not loaded though compiled, resulting in "Call to undefined function" czamora Linux - Software 12 08-01-2006 11:10 AM
"Function not implemented" error in call to "sem_open()" Krishnendu8 Linux - Newbie 1 06-07-2003 02:52 AM
"Function not imlemented" error in call to "sem_open()" Krishnendu8 Linux - Networking 0 06-07-2003 02:19 AM

LinuxQuestions.org > Forums > Non-*NIX Forums > Programming

All times are GMT -5. The time now is 02:57 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration