Re: MyODBC, DBUG and multi-threaded clients
Hi Monty, Michael Widenius wrote: Hi! Sinisa == Sinisa Milivojevic [EMAIL PROTECTED] writes: Sinisa Peter Duffy writes: Hi Sinisa, My problems are within the mysqlclient and MyODBC libraries, both used directly by the application (and therefore all on the client side of the socket.) Both the mysqlclient and MyODBC libraries do (or in my case did) contain calls to the DBUG functions. Obviously, given the fact that the libraries are being called directly by the application, the amount of multi-threading done by the application is most emphatically relevant. cut Just a note about this; I have now updated the section 'How to Make a Thread-safe Client' with more information regarding this. This should be available on our web site shortly. Thanks - I'll look out for this. Regards, Peter - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: MyODBC, DBUG and multi-threaded clients
Hi Monty, Michael Widenius wrote: Hi! I have a small comment to this. Note that you will get crashes in the DBUG package if you call any MySQL function inside a thread that hasn't called mysql_init() or mysql_connect(). If you want to use MySQL functions in threads that doesn't call the above functions, you need to call my_thread_init() at the start of the thread and my_thread_end() before the thread ends. If you think that the DBUG functions are the ones that is causing problems, you can always recompile MySQL without --with-debug, in which the DBUG macros will not generate any code. Regards, Monty Thanks very much for this: I will check the application for these calls. Regards, Peter - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: MyODBC, DBUG and multi-threaded clients
Hi! Sinisa == Sinisa Milivojevic [EMAIL PROTECTED] writes: Sinisa Peter Duffy writes: Hi Sinisa, My problems are within the mysqlclient and MyODBC libraries, both used directly by the application (and therefore all on the client side of the socket.) Both the mysqlclient and MyODBC libraries do (or in my case did) contain calls to the DBUG functions. Obviously, given the fact that the libraries are being called directly by the application, the amount of multi-threading done by the application is most emphatically relevant. cut Just a note about this; I have now updated the section 'How to Make a Thread-safe Client' with more information regarding this. This should be available on our web site shortly. Regards, Monty - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: MyODBC, DBUG and multi-threaded clients
Hi! I have a small comment to this. Sinisa == Sinisa Milivojevic [EMAIL PROTECTED] writes: cut I have no interest in any other clients except possibly to investigate whether or not they produced anything like the same behaviour that I am observing with my own application. My only key objective is to fix my application, which, to repeat again, is coredumping during calls to DBUG functions within the mysqlclient and MyODBC libraries. Regards, Peter Sinisa Exactly what I mean. There are several multithreaded clients out there Sinisa all using libmysqlclient and some MyODBC and none of them experience Sinisa the problems you describe. Note that you will get crashes in the DBUG package if you call any MySQL function inside a thread that hasn't called mysql_init() or mysql_connect(). If you want to use MySQL functions in threads that doesn't call the above functions, you need to call my_thread_init() at the start of the thread and my_thread_end() before the thread ends. If you think that the DBUG functions are the ones that is causing problems, you can always recompile MySQL without --with-debug, in which the DBUG macros will not generate any code. Regards, Monty - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: MyODBC, DBUG and multi-threaded clients
Peter Duffy writes: Hi Sinisa, My problems are within the mysqlclient and MyODBC libraries, both used directly by the application (and therefore all on the client side of the socket.) Both the mysqlclient and MyODBC libraries do (or in my case did) contain calls to the DBUG functions. Obviously, given the fact that the libraries are being called directly by the application, the amount of multi-threading done by the application is most emphatically relevant. First of all DBUG_* are not functions but macros and very simple macros for that fact. And if there was a bug in any of those macros, it would have surfaced in our server or in any of our multi-threaded client, like mysqlmanager. I have no interest in any other clients except possibly to investigate whether or not they produced anything like the same behaviour that I am observing with my own application. My only key objective is to fix my application, which, to repeat again, is coredumping during calls to DBUG functions within the mysqlclient and MyODBC libraries. Regards, Peter Exactly what I mean. There are several multithreaded clients out there all using libmysqlclient and some MyODBC and none of them experience the problems you describe. -- Regards, __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Mr. Sinisa Milivojevic [EMAIL PROTECTED] / /|_/ / // /\ \/ /_/ / /__ MySQL AB, FullTime Developer /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus ___/ www.mysql.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: MyODBC, DBUG and multi-threaded clients
Peter Duffy writes: Hi Sinisa, Do you know of any which are specifically accessed by multi-threaded client applications via ODBC? (If so, I'd really like to know, so that I can try to get hold of copies of the client applications to test in my own environment.) As you very well know, it is completely irrelevant what kind of multi-threaded program it is. Those function perform the same regardless if programs listents to the socket or write to the socket. DBUG functions have got nothing to do with that. There are many such programs utilizing DBUG functions, like mysqlmanagers in tool directory of 4.0. Then several GUI clients. Practically dozens of them. Some of those GUI clients utilizing ODBC. Do some research on your side. I'm sorry about your experiences with mpatrol. As I've said, I find it superb: it has already been of enormous assistance in fixing memory leaks, and in the current situation it gave me information that I could not have gained otherwise. Also, I've always found the author of mpatrol to be highly responsive and helpful. I have not used dmalloc. Best regards, Peter Oh, I had no problems by authors of either mpatrol and dmalloc. I just got reply that my problems lie beyond scopes of their programs and that they will do it one day when they have time, which is OK. -- Regards, __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Mr. Sinisa Milivojevic [EMAIL PROTECTED] / /|_/ / // /\ \/ /_/ / /__ MySQL AB, FullTime Developer /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus ___/ www.mysql.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: MyODBC, DBUG and multi-threaded clients
Hi Sinisa, Sinisa Milivojevic wrote: Peter Duffy writes: Hi Sinisa, Do you know of any which are specifically accessed by multi-threaded client applications via ODBC? (If so, I'd really like to know, so that I can try to get hold of copies of the client applications to test in my own environment.) As you very well know, it is completely irrelevant what kind of multi-threaded program it is. Those function perform the same regardless if programs listents to the socket or write to the socket. DBUG functions have got nothing to do with that. My problems are within the mysqlclient and MyODBC libraries, both used directly by the application (and therefore all on the client side of the socket.) Both the mysqlclient and MyODBC libraries do (or in my case did) contain calls to the DBUG functions. Obviously, given the fact that the libraries are being called directly by the application, the amount of multi-threading done by the application is most emphatically relevant. There are many such programs utilizing DBUG functions, like mysqlmanagers in tool directory of 4.0. Then several GUI clients. Practically dozens of them. Some of those GUI clients utilizing ODBC. Do some research on your side. I have no interest in any other clients except possibly to investigate whether or not they produced anything like the same behaviour that I am observing with my own application. My only key objective is to fix my application, which, to repeat again, is coredumping during calls to DBUG functions within the mysqlclient and MyODBC libraries. Regards, Peter - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
MyODBC, DBUG and multi-threaded clients
I realise that this issue is very specialised, and I'm not sure which mailing list would be best to host a thread based on it, so I'm posting it here to start with: I'm happy to move it to another mysql list if someone would like to suggest one. Over the last year, I've been working on a multi-threaded application (based on OpenLDAP) which queries MySQL via libiodbc and MyODBC (issuing many searches and updates in parallel.) It had been running well and stably, 24 hours a day, for over six months. Then, because of a security vulnerability, I upgraded to the latest version of OpenLDAP, and suddenly the application would not run for more than about three minutes without segfaulting. I've been working on this problem for about three weeks, and I believe I've sorted it: if I'm right, there may be some general implications for MyODBC. My main debugging tool has been mpatrol, a superb and highly-recommended memory-debugging kit. Using this, (aided by coredump examinations in gdb), I found that the segfaults were being caused by attempts to access nonexistent memory: the sources were a number of MyODBC functions (the exact one changed with each test run): the common feature was that in each case, the final address in the mpatrol log traceback pointed to a DBUG_xxx macro (usually DBUG_RETURN). At first, I didn't believe this: then, in an attempt to get more information, I incorporated a patch into the Linux kernel to generate a coredump from the thread which had received the signal (rather than from the application's master thread): the resulting coredump backtraces again pointed to MyODBC source lines containing DBUG macros. I rebuilt mysql without debugging support, then the ODBC libraries and the application. Problem still as above. MyODBC doesn't have a --without-debug option in its configure script (I assume this is because debugging can be activated/deactivated using the debug option in the odbc.ini file.) I therefore went through all the MyODBC code, commenting out all references to the DBUG macros (replacing DBUG_RETURN and DBUG_VOID_RETURN with normal return statements.) I then rebuilt MyODBC and the application. I believe that this gave a result. The application has now been running under full load without segfaulting for over three hours. (That's more than 2h 55m longer than at any time in the last two months. Obviously, it will need to run for a lot longer before I fully trust it again, but I would say that, even at this stage, I'm better than 95% convinced that I've found and eliminated the problem.) Occasionally, within MyODBC, I've seen DBUG_RETURN statements which call MyODBC functions: my best guess at present is that the complex dynamic memory operations going on within these functions is somehow conflicting with DBUG's own dynamic memory management. (I noticed that at the end of the original DBUG manual (mysql-x.xx.xx/dbug/user.r) there is a warning: Programs which use memory allocation functions other than malloc will usually have problems using the standard dbug package. The most common problem is multiply allocated memory.) Has anyone else experienced similar problems with other multi-threaded applications? I guess that two possible ways forward would be either (a) introduce a configure option in MyODBC to totally exclude all the debugging code (as in mysql) - I intend to try this myself; and/or (b) rewrite DBUG's memory allocation to use the facilities in safemalloc. Versions: Linux: Redhat 6.2, kernel 2.2.16-3 (using Terje Malmedal's coredump patch from http://www.movement.uklinux.net - there are a number of patches addressing the threaded coredump issue, but this one was specific for my kernel and it sure as hell did the business 8)) OpenLDAP: originally 2.0.7, then 2.0.11. mysql: 3.23.38 MyODBC: 2.50.33 libiodbc: 3.0.5 mpatrol: 1.4.5 (http://www.cbmamiga.demon.co.uk/mpatrol) - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: MyODBC, DBUG and multi-threaded clients
Peter Duffy writes: Versions: Linux: Redhat 6.2, kernel 2.2.16-3 (using Terje Malmedal's coredump patch from http://www.movement.uklinux.net - there are a number of patches addressing the threaded coredump issue, but this one was specific for my kernel and it sure as hell did the business 8)) OpenLDAP: originally 2.0.7, then 2.0.11. mysql: 3.23.38 MyODBC: 2.50.33 libiodbc: 3.0.5 mpatrol: 1.4.5 (http://www.cbmamiga.demon.co.uk/mpatrol) Hi! As an example, mysql server is a multi-threaded program and when compile --with-debug it uses DBUG function. There are literally thousands and thousands of locations where mysql server built for debugging is running, without a single problem being caused by those routines. Furthermore, these routines have not been changed for years and have been thoroughly checked with Purify and Pure Coverage which are much better tools then mpatrol. I have my own reservations regarding mpatrol and dmalloc. None of them, for example, worked with my C++ programs. They just crashed/ refused to work. I have tried latest versions and wrote to the authors. That was more then one year ago. It is possible that meanwhile this situation has been fixed. -- Regards, __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Mr. Sinisa Milivojevic [EMAIL PROTECTED] / /|_/ / // /\ \/ /_/ / /__ MySQL AB, FullTime Developer /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus ___/ www.mysql.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: MyODBC, DBUG and multi-threaded clients
Hi Sinisa, Sinisa Milivojevic wrote: As an example, mysql server is a multi-threaded program and when compile --with-debug it uses DBUG function. I know. As I said, one of my main problems is that MyODBC does not have a --without-debug option. There are literally thousands and thousands of locations where mysql server built for debugging is running, without a single problem being caused by those routines. Do you know of any which are specifically accessed by multi-threaded client applications via ODBC? (If so, I'd really like to know, so that I can try to get hold of copies of the client applications to test in my own environment.) Furthermore, these routines have not been changed for years and have been thoroughly checked with Purify and Pure Coverage which are much better tools then mpatrol. I don't doubt that the routines have been thoroughly checked. However, I am talking about specific problems and specific observations in my own work. The application coredumped; the backtraces (persistently) pointed me at the DBUG_ calls in MyODBC; I commented-out the calls; the situation vastly improved. If you could suggest an alternative explanation and approach, I'd be happy to hear it. I have my own reservations regarding mpatrol and dmalloc. None of them, for example, worked with my C++ programs. They just crashed/ refused to work. I have tried latest versions and wrote to the authors. That was more then one year ago. It is possible that meanwhile this situation has been fixed. I'm sorry about your experiences with mpatrol. As I've said, I find it superb: it has already been of enormous assistance in fixing memory leaks, and in the current situation it gave me information that I could not have gained otherwise. Also, I've always found the author of mpatrol to be highly responsive and helpful. I have not used dmalloc. Best regards, Peter - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
