[unixODBC-support] unixODBC-support Digest, Vol 9, Issue 2

Eran Falk ERANFA at cellcom.co.il
Thu Mar 3 08:33:38 GMT 2005



-----Original Message-----
From: unixodbc-support-bounces at easysoft.com
[mailto:unixodbc-support-bounces at easysoft.com] On Behalf Of
unixodbc-support-request at easysoft.com
Sent: Thursday, March 03, 2005 6:04 AM
To: unixodbc-support at easysoft.com
Subject: unixODBC-support Digest, Vol 9, Issue 2


Send unixODBC-support mailing list submissions to
	unixodbc-support at easysoft.com

To subscribe or unsubscribe via the World Wide Web, visit
	http://mail.easysoft.com/mailman/listinfo/unixodbc-support
or, via email, send a message with subject or body 'help' to
	unixodbc-support-request at easysoft.com

You can reach the person managing the list at
	unixodbc-support-owner at easysoft.com

When replying, please edit your Subject line so it is more specific than
"Re: Contents of unixODBC-support digest..."


Today's Topics:

   1. Re: driver logging  (Eric Sharkey)
   2. Re: driver logging (Nick Gorham)
   3. Re: driver logging (Vinicius)
   4. Re: driver logging (Nick Gorham)
   5. Re: driver logging  (Eric Sharkey)
   6. Re: driver logging (Nick Gorham)
   7. Re: driver logging  (Eric Sharkey)
   8. Re: driver logging (Nick Gorham)
   9. Re: driver logging (martin.evans at easysoft.com)
  10. Shared lib crash on load when linked with -lodbc	or dlopen
      called (Zachary Bedell)


----------------------------------------------------------------------

Message: 1
Date: Wed, 02 Mar 2005 12:00:31 -0500
From: Eric Sharkey <sharkey at netrics.com>
Subject: Re: [unixODBC-support] driver logging 
To: Support for the unixODBC project <unixodbc-support at easysoft.com>
Message-ID: <E1D6XD5-0007o9-00 at cyclops.netrics.internal>

> Not being in the main line of the code and the driver manager makes me
> worry a lot less about the potential support issues. Its anways a 
> --enable-drivers=no away :-)

The logical place to put a (v)snprintf implementation is in
libodbcextras along side the current strncasecmp and the vms support
functions.

Do you not have a header for this lib?  It looks like the main line of
code calls strncasecmp in only one place,
odbcinst/SQLManageDataSources.c.

Shouldn't you have a header for this library?

Eric


------------------------------

Message: 2
Date: Wed, 02 Mar 2005 17:09:01 +0000
From: Nick Gorham <nick.gorham at easysoft.com>
Subject: Re: [unixODBC-support] driver logging
To: Support for the unixODBC project <unixodbc-support at easysoft.com>
Message-ID: <4225F32D.6000801 at easysoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed

Eric Sharkey wrote:

>>Not being in the main line of the code and the driver manager makes me
>>worry a lot less about the potential support issues. Its anways a 
>>--enable-drivers=no away :-)
>>    
>>
>
>The logical place to put a (v)snprintf implementation is in 
>libodbcextras along side the current strncasecmp and the vms support 
>functions.
>
>Do you not have a header for this lib?  It looks like the main line of 
>code calls strncasecmp in only one place, 
>odbcinst/SQLManageDataSources.c.
>
>Shouldn't you have a header for this library?
>  
>
Yes.

-- 
Nick


------------------------------

Message: 3
Date: Wed, 02 Mar 2005 15:32:13 -0300
From: Vinicius <vpd at jppa.com.br>
Subject: Re: [unixODBC-support] driver logging
To: Support for the unixODBC project <unixodbc-support at easysoft.com>
Message-ID: <422606AD.1030309 at jppa.com.br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

how I unsubscribe this list??

Eric Sharkey escreveu:

>>Yep. However beware, you have to make sure the varargs stuff and the
>>vsnprintf works on some of the odd platforms that people use this
stuff 
>>on.
>>    
>>
>
>I understand that very well.  (I sent you an OpenVMS patch, remember?)
>
>  
>
>>Maybe having a vlogPushMsg would be a way of doing this.
>>    
>>
>
>Yes, it absolutely would have to be a separate function.  I shouldn't 
>have used the same name in the example I gave.
>
>The main problem with just changing the behavior of logPushMsg to 
>expect a format string followed by additional arguments would be that 
>any code using the current logPushMsg() would be exposed to format 
>string security vulnerabilities, since they wouldn't be expecting to 
>have to escape %'s.
>
>I can code this up, make sure it works on the platforms I support, and 
>commit it if you like.
>
>Eric
>_______________________________________________
>unixODBC-support mailing list
>unixODBC-support at easysoft.com 
>http://mail.easysoft.com/mailman/listinfo/unixodbc-support
>
>  
>


------------------------------

Message: 4
Date: Wed, 02 Mar 2005 18:43:00 +0000
From: Nick Gorham <nick.gorham at easysoft.com>
Subject: Re: [unixODBC-support] driver logging
To: Support for the unixODBC project <unixodbc-support at easysoft.com>
Message-ID: <42260934.40100 at easysoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed

Vinicius wrote:

> how I unsubscribe this list??


Click on the link at the bottom of the email, that will allow you to
unsub.

-- 
Nick


------------------------------

Message: 5
Date: Wed, 02 Mar 2005 14:21:09 -0500
From: Eric Sharkey <sharkey at netrics.com>
Subject: Re: [unixODBC-support] driver logging 
To: Support for the unixODBC project <unixodbc-support at easysoft.com>
Message-ID: <E1D6ZPB-0005x3-00 at mastermind.netrics.internal>

> >Shouldn't you have a header for this library?
> >  
> >
> Yes.

Ok, I've added a uodbc_extras.h in my working directory.  I'm running up
against some libtool issues while trying to build the CVS version,
though.


What versions of the autotools do you use for compiling the
CVS versions?

I tried and failed to build with aclocal-1.9/automake-1.9.  It looks
like the ltmain.sh in the unixODBC source is just too old for these
tools to build unixODBC, since the libtool script created doesn't
support the --tag option generated by automake-1.9.

Eric


------------------------------

Message: 6
Date: Wed, 02 Mar 2005 19:55:24 +0000
From: Nick Gorham <nick.gorham at easysoft.com>
Subject: Re: [unixODBC-support] driver logging
To: Support for the unixODBC project <unixodbc-support at easysoft.com>
Message-ID: <42261A2C.1090200 at easysoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed

Eric Sharkey wrote:

>>>Shouldn't you have a header for this library?
>>> 
>>>
>>>      
>>>
>>Yes.
>>    
>>
>
>Ok, I've added a uodbc_extras.h in my working directory.  I'm running 
>up against some libtool issues while trying to build the CVS version, 
>though.
>
>
>What versions of the autotools do you use for compiling the CVS 
>versions?
>
>I tried and failed to build with aclocal-1.9/automake-1.9.  It looks 
>like the ltmain.sh in the unixODBC source is just too old for these 
>tools to build unixODBC, since the libtool script created doesn't 
>support the --tag option generated by automake-1.9.
>  
>

aclocal --version
aclocal (GNU automake) 1.6.3

I guess it should be updated sometime, problem is I have to use a 
patched libtool for a coupel of build problems on things like unixware 
and some older AIX's, so every time I update, its 6 month until all the 
changes are remembered and repeated.

-- 
Nick


------------------------------

Message: 7
Date: Wed, 02 Mar 2005 16:01:58 -0500
From: Eric Sharkey <sharkey at netrics.com>
Subject: Re: [unixODBC-support] driver logging 
To: Support for the unixODBC project <unixodbc-support at easysoft.com>
Message-ID: <E1D6ayk-0006U3-00 at mastermind.netrics.internal>

> aclocal --version
> aclocal (GNU automake) 1.6.3

Thanks.  1.6 seems to be working.

How do you want to handle this?  Do you want to do a 2.2.11 release
before I commit this?

Eric


------------------------------

Message: 8
Date: Wed, 02 Mar 2005 21:14:32 +0000
From: Nick Gorham <nick.gorham at easysoft.com>
Subject: Re: [unixODBC-support] driver logging
To: Support for the unixODBC project <unixodbc-support at easysoft.com>
Message-ID: <42262CB8.6060706 at easysoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed

Eric Sharkey wrote:

>>aclocal --version
>>aclocal (GNU automake) 1.6.3
>>    
>>
>
>Thanks.  1.6 seems to be working.
>
>How do you want to handle this?  Do you want to do a 2.2.11 release 
>before I commit this?
>  
>
Yes, I think thats a good idea. I will do that tommorow.

-- 
Nick


------------------------------

Message: 9
Date: Wed,  2 Mar 2005 21:58:13 +0000
From: martin.evans at easysoft.com
Subject: Re: [unixODBC-support] driver logging
To: Support for the unixODBC project <unixodbc-support at easysoft.com>
Message-ID: <1109800693.422636f56c71c at maya.easysoft.local>
Content-Type: text/plain; charset=ISO-8859-1

You might want to get into the habit of looking at email headers when
you are subscribed to lists. The email sent to you had in the header:

List-Unsubscribe:
<http://mail.easysoft.com/mailman/listinfo/unixodbc-support>, 
	
<mailto:unixodbc-support-request at easysoft.com?subject=unsubscribe>

Martin

Quoting Vinicius <vpd at jppa.com.br>:

> how I unsubscribe this list??
> 
> Eric Sharkey escreveu:
> 
> >>Yep. However beware, you have to make sure the varargs stuff and the
> >>vsnprintf works on some of the odd platforms that people use this
stuff 
> >>on.
> >>    
> >>
> >
> >I understand that very well.  (I sent you an OpenVMS patch, 
> >remember?)
> >
> >  
> >
> >>Maybe having a vlogPushMsg would be a way of doing this.
> >>    
> >>
> >
> >Yes, it absolutely would have to be a separate function.  I shouldn't

> >have used the same name in the example I gave.
> >
> >The main problem with just changing the behavior of logPushMsg to 
> >expect a format string followed by additional arguments would be that

> >any code using the current logPushMsg() would be exposed to format 
> >string security vulnerabilities, since they wouldn't be expecting to 
> >have to escape %'s.
> >
> >I can code this up, make sure it works on the platforms I support, 
> >and commit it if you like.
> >
> >Eric
> >_______________________________________________
> >unixODBC-support mailing list
> >unixODBC-support at easysoft.com 
> >http://mail.easysoft.com/mailman/listinfo/unixodbc-support
> >
> >  
> >
> _______________________________________________
> unixODBC-support mailing list
> unixODBC-support at easysoft.com 
> http://mail.easysoft.com/mailman/listinfo/unixodbc-support
> 
> 
> 





------------------------------

Message: 10
Date: Wed, 2 Mar 2005 23:03:56 -0500
From: Zachary Bedell <zaclist at adirondack.net>
Subject: [unixODBC-support] Shared lib crash on load when linked with
	-lodbc	or dlopen called
To: unixodbc-support at easysoft.com
Message-ID: <ef19a09f3fea17c4aff1574377ef4057 at adirondack.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all!

I really hate to post this to the mailing list because I feel too much 
like a begging newbie.  It seems like I must be missing something 
obvious, but after three days of solid hacking, I'm still in the dark.  
That said, I *am* a newbie when it comes to ODBC as this is only the 
second project I've tried with unixODBC.  (The first project is working 
pretty well now, so I know how to do something right.)

I'm working on porting some Windows ODBC code to run under Linux 
(kernel 2.4, libc 2.3.4, gcc 3.3.4 on Gentoo with unixODBC 2.2.10).  
The code is part of a shared object that is loaded as a plugin to the 
Helix DNA server from RealNetworks.  The Windows version of this code 
is known to work.  I thought this would be an easy port job, but I 
guess that's what I get for thinking...

The Windows code uses LoadLibrary to load odbc32.dll and GetProcAddress 
to get function pointers.  My first attempt was to convert the function 
pointer calls to direct calls and link with -lodbc.  That compiled 
fine, but as soon as Helix loaded the module, it would crash with 
SIGCHLD.  Linking that without -lodbc didn't crash Helix, but it of 
course complained as soon as it tried to access any of the ODBC 
functions since the symbols didn't resolve.

I switched to manually calling dlopen to load the library and dlsym to 
get pointers to the various functions.  I probably should have started 
that way as it was much less work.  A few macros to map the parameters 
from LoadLibrary, GetProcAddress, and FreeLibrary onto dlopen, dlsym, 
and dlclose; and I was done.  That way, the library loads successfully 
and properly queries the database.  Unfortunately right after Helix 
deconstructs the class, it SIGCHLD's again.  I found that if I run with 
the call to dlopen commented, the server does not crash.  Also, if I 
comment out all the function bodies and ONLY call dlopen, then the 
server still crashes after deconstructing the last instance of the 
class.

I've managed to narrow down the original cause of my crashes to the act 
of loading the unixODBC libodbc.so.  If I don't load the library, I 
don't crash.  If I do load the library, even if I don't do anything 
else, I still crash.  I've also tried using both FreeTDS and MyODBC as 
the drivers with unixODBC.  The behavior's the same with both, so I'm 
pretty confident that rules out FreeTDS as the cause.

I'll try to describe as much as I can about the environment that I'm 
calling unixODBC from, in case any of these details are helpful: The
code has a global void * that holds a handle returned from dlopen 
and a number of global function pointers for the ODBC API functions.  
The .cpp file for this object contains static functions (not class 
members) that call dlopen and dlsym before the first time the ODBC 
functions are needed.  The LoadODBCLibrary function is called each time 
the database portion of the class is initialized, and each time it 
checks to see if the global handle to the library is NULL.  If the 
handle is non-NULL, it does nothing as some previous invocation has 
already loaded the library.  I've confirmed (with printf's) that dlopen 
is only called once.

The global function pointers survive multiple instantiations of the 
class and dlclose is finally called when Helix sends a shutdown message 
to the plugin (another static function defined by Helix's plugin API).  
I've got the code filled up with printf's at the moment, and I've 
confirmed that Helix is never sending the shutdown message and the 
nothing is trying to call dlclose before the crash  (that's as it 
should be since Helix would ordinarily keep running and continue using 
the ODBC library).  I can also see that the object is created and 
destroyed multiple times during Helix's startup routines without any 
problem.  The catch is that those startup routines don't load the ODBC 
library.  That happens later only when the database portion of the 
class is init'ed.  Once the library IS loaded, then once all the 
instances of the class are released, Helix crashes.  I've confirmed 
using printf's in my code and with additional debugging message that 
Helix produces that control has returned to Helix (outside of my 
object) before it crashes.  The deconstructor method of my class 
completes and no other functions in my code are called between the end 
of the deconstructor and the crash.  There is a debug message from 
Helix that announces it's deleting the Client object that was using my 
code, and a few milliseconds later it crashes.  The deconstructor 
doesn't call dlclose nor touch the function pointers at all.

Up until the crash, the ODBC library is functioning correctly.  It does 
successfully query and return data from my MS SQL Server or MySQL.


So I feel like a heel begging for help here.  The project in question 
is only sort-of open source as you need to execute a clickwrap 
agreement to get it.  That said, I'm totally clueless and would REALLY 
appreciate any debugging pointers that might help me track down what's 
going on here.  Is there anything magic I can do to debug what might be 
happening in libodbc or elsewhere after my code is done?  Is there any 
code in the ODBC libraries that could execute "on its own" after all of 
the various handles are released?  I'll take anything at all!

Thanks in advance,
Zac Bedell

======================================================
It is better to give than to lend, and it costs about the same.

- ------------------------------------------------------
Brought to you by MacOS, running on host Ringo
Running for:  7 days,  2 hours, 57 minutes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iEYEARECAAYFAkImjLAACgkQq+EtLVpY/F48UgCgkX6xvF1CI3SvkHJQRscST8YT
vqgAnAjXpHHBcg381GGlPVTCGE14MMT4
=q54u
-----END PGP SIGNATURE-----



------------------------------

_______________________________________________
unixODBC-support mailing list
unixODBC-support at easysoft.com
http://mail.easysoft.com/mailman/listinfo/unixodbc-support


End of unixODBC-support Digest, Vol 9, Issue 2
**********************************************


---------------------------------------------------------------------------------------------------------------
This e-mail message may contain confidential, commercial and privileged information or data that constitute proprietary information of Cellcom Israel Ltd. Any review or distribution by others is strictly prohibited. If you are not the intended recipient you are hereby notified that any use of this information or data by any other person is absolutely prohibited. If you are not the intended recipient, please delete all copies.

Thank You.
http://www.cellcom.co.il







More information about the unixODBC-support mailing list