col wrote: > On Fri, 26 Jun 2009 08:44:28 +0200 "John Escott" <j...@scanlaser.nl> > wrote: > >> (the first reply in the same page) helpful, since unixODBC 2.2.8 is >> the default version in RHEL3 and a recent Fedora containing 2.2.11 >> worked correctly. > > John -- > > Thanks for your reply. Actually, the problem is consistent and > appears only *after* unixODBC version 2.2.11 -- that is the very last > version that works. All subsequent releases exhibit this segmentation > fault failure. > > So far nothing suggested to apply in the compile stage is fixing it.
Can I just verify whether you have configured unixODBC then removed the LT_GLOBAL from the dlopen call then configured again and ensured LT_GLOBAL is in the dlopen call. One of those should fix it - I believe it is the removing of LT_GLOBAL. One of the FAQs suggests LT_GROUP needs removing but I thought it was LT_GROUP which needed to be in place. The problem this addresses is dynamic resolution of symbols. The perl runs and DBI loads ODBC.so which is linked to libodbc.so. When you call DBI->connect, unixODBC will load the driver and locate the symbols but once this has happened the next call to a SQLxxx ODBC fn ends up directly in the ODBC driver instead of in unixODBC. As your application had a connection handle given to it via unixODBC, the first ODBC call after connect from the app/DBD::ODBC ends up in the SQLxxx fn in the driver with a unixODBC handle instead of a driver handle then when the driver attempts to use that pointer it can easily segfault because it points at a structure it never created. If this was your problem then you could identify it precisely by enabling unixODBC logging and doing a simple connect (which segfaults) - is there anything in the log? e.g., add the following to your odbcinst.ini file: [ODBC] Trace = yes TraceFile = /tmp/unixodbc.log > The ld.so.preload hack is not a fix at all IMO, but I'm neither C > programmer, nor distro packager. I just dislike ugly hacks and as a > "sysadmin", *really* wouldn't mind never thinking of this again. >From the above explanation you can maybe see how this fixes it. At this stage you only have a few choices a) throw it all away and stop using it b) use the "ugly hack" c) try more to get to the bottom of it. My guess is you won't be doing (a) and will almost certainly do (b) until someone sorts it out for you - but that will probably require more of (c). > Unfortunately, I'm just not in a position to figure it out. I've done > my bit to complain and report on this since version 2.2.12 broke my > system, all to no effect. Someone else has to want to fix this. The first problem here is we are not sure what problem you have - we can only guess based on the "ugly hack". The second problem is other than John (who is working now) you are the only person with this problem - I don't have it on Linux Ubuntu using either unixODBC and freeTDS supplied by Ubuntu or when I build everything myself. Neither does anyone else I know (and I know a lot (1000s) of people using unixODBC). If we had access to the machine which is failing we might be able to find out what is wrong but in the mean time we are still not 100% sure what the problem is and we are not sure what exactly you have tried. "since version 2.2.12 broke my system, all to no effect. Someone else has to want to fix this." I don't want to get into an argument with you about this but I think "all to no effect" is a little unfair. You got responses to your request for help almost immediately, you say you have tried some and now just want to give up and say it is someone else's problem. It is not my problem or anyone elses - all the software you are using is free and there is no obligation on anyone I know to help you but some are trying. You also seem to have a workaround but you don't like it. > It was suggested that Debian actually has this working "out of the > box", but I'm guessing they have a ld.so.preload hack for it to work, > or maybe they package an older version that still works, like 2.2.11 > (I guess that's what you just wrote). It works "out of the box" for me on ubuntu as well and also with the latest of unixODBC and freeTDS built by hand and with preload untouched. > I suppose I could just go back to that version too, but 2.2.12 was > out a long time ago and 2.2.14 is the latest. I mean, aren't we > supposed to help fix bugs for new releases? I am not sure what you mean by that. > Anyway, the problem is known, the fix should be made available, but > first, there has to be an acknowledgement of the problem by unixODBC > folks, something I've yet to see... it's almost as if there was some > *other way* to do this... *not* using FreeTDS. Otherwise, this would > be a major problem with the package, and something necessitating a > fix, no? A fix might be made available once someone has identified the problem - that has not happened yet. I personally dislike your comments made at people who wrote and maintain a large piece of software for free. I was going to say more but I've bitten my tongue instead. > Anyway, I'm done ranting. Time for me to just accept defeat in this > area and move on. Does anyone know, is there an open source > replacement for unixODBC? Why do we need this thing anyway for > DBD::ODBC? Shouldn't it work without it? There is iODBC - problem is, it works just like unixODBC in respect of loading the driver so there is no guarantee that will get you anywhere. I could explain why you need an ODBC Driver Manager but if you do a search you can find out for yourself. Try building freeTDS with DBD::ODBC without one or (use threads or unicode) and you'll soon see why. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
