Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


codingJoe

Member Since 22 Oct 2012
Offline Last Active Sep 11 2014 07:25 AM

Posts I've Made

In Topic: Rendering large meshes in OpenGl

11 September 2014 - 07:25 AM

Thank you for your good replies, you have been very helpful. I could already slightly increase the rendering speed!


In Topic: My sockets are as fast as pipes..

14 April 2014 - 05:23 PM

Thanks for the insightful comments!

So if I understood correctly, using shared memory is the solution. But still no guarantee for a speed increase.

I'll try my hands on this, thanks again


In Topic: Function addresses are not fixed relative to each other?

17 July 2013 - 08:37 AM

Thanks for all the interesting inputs! It was for me a little bit too much in-depth though ;)

 

Returning to my initial problem, I would be very curious if someone finds out what is going on because it is extremely mysterious to me:

 

1) I am not doing any fancy things. Specially not memory manipulation, etc.

2) The strange thing only happens on Linux. Windows and Mac run fine.

3) The application is cross-platform and based on Qt.

4) When working with Qt4.8, the problem doesn't happen on Linux. With Qt5.1.0, yes, even if the compiler is the same g++ 4.6.3

5) And here the actual mysterious thing:

 

a) I have a library LIB that exports several API functions. I also have a client application APP that dynamically loads the LIB and binds ALL of its functions at once.

b) Internally, the LIB itself calls some of its exported API functions

c) If APP calls the API function X, or rather just "mentions" a call to the API function X (i.e. the function doesn't need to be executed), then the LIB cannot call the same function, because the function pointer is invalid for the LIB (but working for the APP)

d) if a second APP, say APP2 doesn't call and doesn't "mention" a call to the API function X, then the LIB can call the function X and it works (i.e. no crash with APP2)

e) between c) and d) the LIB has not changed. It is exactly the same file. I verified also that the crash is linked to the function pointer X being invalid internally

 

To summarize above explanations, here a typical example:

 

LIB, file1:

void randomFunction()
{
    printHello(); // internally calling the API function that this LIB exports
}

LIB, file2:

extern "C" __attribute__((visibility("default"))) void printHello()
{ // one of the functions that this LIB exports
    printf("Hello\n");
}

APP:

int main(int argc,char* argv[])
{
    // Dynamically load LIB with: lib=dlopen(pathAndFilename,RTLD_LAZY)
    // Bind ALL API functions with: dlsym(lib,funcName);
    for (int i=0;i<10000000000;i++)
        printf("."); // just spend "almost" infinite time here
    printHello(); // this is actually never executed. But if we remove the loop here above, this function would execute correctly
}

APP2:

int main(int argc,char* argv[])
{
    // Dynamically load LIB with: lib=dlopen(pathAndFilename,RTLD_LAZY)
    // Bind ALL API functions with: dlsym(lib,funcName);
    for (int i=0;i<10000000000;i++)
        printf("."); // just spend "almost" infinite time here
    // printHello(); 
}

The difference between APP and APP2 is minimal. The LIB that APP and APP2 load and bind is exactly the same. However, only with APP2 can the LIB function 'randomFunction' safely call 'printHello'. With APP, 'randomFunction' executes only to the point where 'printHello' has to be called, then crashes. Verifying the 'printHello' function address inside that 'randomFunction' reveals an illegal address --> it is logical that it crashes, but not logical that the address is illegal with APP and not illegal with APP2.

 

Did I make sense? I am already trying to figure out what is going on since a few days, and the more I move forward, the more I feel lost..


In Topic: Function addresses are not fixed relative to each other?

15 July 2013 - 04:22 AM

Thanks Khatharr,

 

I had a look at the link which is very exhaustive, but probably too much Windows oriented.

I am using g++ V4.6.3 under Ubuntu. It is invoked under the whoods by Qt (Qt V5.1.0).

You are telling me that functions can get shifted around when loaded into memory, and the loader/binder takes care of correcting for that. But it seems that in my case, the loader fails at doing its job correctly:

 

I have library-internal calls to functions A and B too. And those calls will sometimes call the wrong address (as strangely as it seems!). My library and client application run on Windows, Mac and Linux. Windows and Mac run fine. Linux used to run fine until I switched to the newest Qt version (but still same compiler). Is it possible that Qt appended additional compilation flags that influence the way my library gets loaded?


In Topic: Function addresses are not fixed relative to each other?

14 July 2013 - 06:31 PM

Thank you swiftcoder.

 

Yes, I understand that the functions should all get a same offset, but is it possible that one function gets a different offset that the others?

 

Let's say, that I have 2 functions in my library: A() and B().

My client application loads the library and binds the functions. I print location of function B RELATIVE to the location of functions A:

 

A-B=position of function B relative to function A=X

 

My question is: will X always be the same for the same library binary? Could it be that the library loaded decided one time to put function B before function A? (and vice-versa)


PARTNERS