(that was already sent to [EMAIL PROTECTED])
>Description:
Programs, compiled with mysql++ on that machine, abort with a
segfault at an attempt to connect to the mysql server, while
programs using Mysql C API (for instance, mysql's own
benchmark suite) and the same programs executed on a local
Linux machine run OK.
I used mysql++-1.7.8 and recent stable 3.26.36 mysql (source).
According to debugger's backtrace, it stops with signal 11
(and message: 'Segmentation fault (core dumped)') in mysql
connection / memory allocation code:
(gdb) bt
#0 0xef545c18 in _malloc_unlocked ()
#1 0xef545b38 in malloc ()
#2 0xef78acec in my_malloc ()
#3 0xef7899c0 in vio_new ()
#4 0xef786a28 in mysql_real_connect ()
#5 0xef5c6568 in MysqlConnection::real_connect ()
#6 0xef5c5e74 in MysqlConnection::MysqlConnection ()
#7 0x2e398 in main () at test1.cc:9
It is not only my programs that fail like that, all the
mysql++ examples abort exactly this way.
Interestingly enough, one of the programs I use behave a bit
differently. It starts with "Bad free() ignored" message
and stops with 'Abort (core dumped)' message. Debugger produces
the following backtrace (formatted manually for readability):
(gdb) bt
#0 0xef50828c in _libc_kill ()
#1 0xef4ba608 in abort ()
#2 0xef578bd0 in Letext ()
#3 0xef578c00 in __terminate ()
#4 0xef579708 in throw_helper (eh=0xef59be4c, pc=0xef5c7bff,
my_udata=0xefffec70, offset_p=0xefffec6c)
#5 0xef579910 in __throw ()
#6 0xef5c7c00 in MysqlConnection::execute ()
#7 0x111e38 in basic_string<char, string_char_traits<char>,
__default_alloc_template<false, 0> >::unique ()
#8 0x10f51c in basic_string<char, string_char_traits<char>,
__default_alloc_template<false, 0> >::append ()
#9 0x10af58 in MysqlQuery::~MysqlQuery ()
#10 0x4193c in _init ()
#11 0x3b6b4 in _init ()
#12 0x3cb04 in _init ()
#13 0x3dfb8 in _init ()
The more detailed report and listing of debugger outputs and
some code is available online for your reference at:
http://netec.mcc.ac.uk/HoPEc/g4/mysql-problem-details.txt
I've tried several versions of mysql deamon (mentioned in the
details doc), and to recompile mysql and mysql++ several times
with two versions of gcc (2.95.1 and 2.95.2) and with different
options (according to Mysql Documentation/installation/system
specific/Solaris recommendations), with little success and minimal
changes of soft behaviour.
I've also tried --safe-mode and --loging but that didn't make
situation clear, but please look into the details file mentioned
above: may be for you it will make something clear.
>How-To-Repeat:
should be obvious from the above description
>Fix:
no idea, sorry
>Submitter-Id: <submitter ID>
>Originator: ivan kurmanov, [EMAIL PROTECTED]
>Organization:
RePEc, http://repec.org
>MySQL support: none
>Synopsis: <synopsis of the problem (one line)>
>Severity: critical
>Priority: high
>Category: mysql mysql++
>Class: sw-bug
>Release: mysql-3.23.36 (Source distribution)
>Environment:
Library used: Mysql++ 1.7.8
System: SunOS irwell 5.6 Generic_105181-20 sun4u sparc SUNW,Ultra-Enterprise
Architecture: sun4
Some paths: /home/adnetec/usr/local/bin/perl /home/adnetec/bin/make
/usr/local/bin/gmake /home/adnetec/usr/local/bin/gcc /opt/SUNWspro/bin/cc
GCC: Reading specs from
/home/adnetec/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/specs
gcc version 2.95.2 19991024 (release)
Compilation info: CC='gcc' CFLAGS='-O6 ' CXX='c++' CXXFLAGS='-O6
-fomit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti ' LDFLAGS=''
LIBC:
-rw-r--r-- 1 bin bin 1608144 Feb 7 2000 /lib/libc.a
lrwxrwxrwx 1 root root 11 Jun 21 1999 /lib/libc.so -> ./libc.so.1
-rwxr-xr-x 1 bin bin 1014272 Feb 7 2000 /lib/libc.so.1
-rw-r--r-- 1 bin bin 1608144 Feb 7 2000 /usr/lib/libc.a
lrwxrwxrwx 1 root root 11 Jun 21 1999 /usr/lib/libc.so -> ./libc.so.1
-rwxr-xr-x 1 bin bin 1014272 Feb 7 2000 /usr/lib/libc.so.1
Configure command: ./configure --prefix=/home/adnetec/Ivan
--with-unix-socket-path=/home/adnetec/Ivan/tmp/mysql.socket --with-low-memory
--enable-assembler
Perl: This is perl, version 5.005_02 built for sun4-solaris
NB: I didn't send this report with mysql-bug script, I just used its
output for this message as draft, because I couldn't send mail from that
machine, it is remote for me. Sorry, if that sets any limits to
usefulnes of this report.
Ivan
---------------------------------------------------------------------
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
