[unixODBC-dev] lt_dlerror may cause potential issue in multi-thread environment

xiaonan xn212516 at 163.com
Fri Apr 12 10:51:38 BST 2013


Hi, Nick:

    Your response:
     a context shift can happen between dlopen and dlerror so the error may relate to the other thread.

    Because there is a lock, why other threads can enter this critical Section? Thanks!

Best Regards
Nan Xiao
At 2013-04-12 14:59:02,"Nick Gorham" <nick at lurcher.org> wrote:

On 12/04/13 02:40, xiaonan wrote:

 Hi, Nick:

    Because lt_dlerror() function is not thread-safe, in the following code:


Ok, I misunderstood your problem. I would say the solution is to wrap the calls with the mutext to force it into being thread safe. But you still run the risk if the driver does the same thing and not using the mutext so it will still have the same problem.

    
    if ( !(connection -> dl_handle = odbc_dlopen( driver_lib )))
    {
        char txt[ 2048 ];

        sprintf( txt, "Can't open lib '%s' : %s",
                driver_lib, lt_dlerror());

        ......
        
        return 0;
    }
    
    In multi-thread environment, the lt_dlerror() may return other thread's error, or even NULL.
    
    In your latest modif! ication:
    
    if ( !(connection -> dl_handle = odbc_dlopen( driver_lib )))
    {
        char txt[ 2048 ];
        const char *err;

        err = lt_dlerror();

        sprintf( txt, "Can't open lib '%s' : %s",
                driver_lib, err ? err : "NULL ERROR RETURN" );

        ......
        return 0;
    }
    
    This issue still exits.
    
    Personally, I think the function of odbc_dlopen() can be modified as this:
    
    static void *odbc_dlopen( char *libname, cha! r *err );
    {
        ......
        hand = lt_dlopen( libname );
        if (hand)
        {
        }
        else
        {
            sprintf(err, "%s", lt_dlerror());
        }
    }


Bit that still doesnt help. a context shift can happen between dlopen and dlerror so the error may relate to the other thread. If I understand correctly, all you have done is reduce the time between the dlopen and dlerror, its still not atomic.

--
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.unixodbc.org/pipermail/unixodbc-dev/attachments/20130412/a73dbb82/attachment.html>


More information about the unixODBC-dev mailing list