nss-mysql-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Nss-mysql-devel] [Bug #757] Segfault which appears to be in nss-mysql.


From: nobody
Subject: [Nss-mysql-devel] [Bug #757] Segfault which appears to be in nss-mysql.
Date: Thu, 20 Feb 2003 05:03:27 -0500

=================== BUG #757: LATEST MODIFICATIONS ==================
http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=757&group_id=443

Changes by: Guillaume Morin <address@hidden>
Date: 2003-Feb-20 11:03 (Europe/Paris)

            What     | Removed                   | Added
---------------------------------------------------------------------------
              Status | Open                      | Closed


------------------ Additional Follow-up Comments ----------------------------
Great! Thanks for telling me.

Guillaume.



=================== BUG #757: FULL BUG SNAPSHOT ===================


Submitted by: kyrian                  Project: NSS MySQL                    
Submitted on: 2002-Jun-26 04:44
Category:  None                       Severity:  5 - Major                  
Bug Group:  None                      Resolution:  None                     
Assigned to:  gmorin                  Status:  Closed                       

Summary:  Segfault which appears to be in nss-mysql.

Original Submission:  Hi,

This segfault problem comes about when using the frontpage extensions for 
linux, so it may well be a problem with that passing garbage to nss-mysql (even 
if that is the case, it's still a BAD problem!), or it could be a problem 
within nss-mysql itself, which is what I think is the case.

Basically what appears to be happening (guesswork, see the attached strace 
information - sorry about the format, daft X setup left me no choice - for more 
conclusive info) is that when the frontpage software attempts to look up a 
(non-existent in /etc/passwd, as per my /etc/nsswitch.conf configuration) UID 
to username mapping, in some cases, you get a segfault, whereas if I add the 
appropriate user line in /etc/passwd, I get no segfault, because I've 
circumvented nss-mysql...

Now, from the attached strace, I reckon that this is happening because when 
reading /etc/nss-mysql.conf, there is an old_mmap() call which gets a buffer 
space of 4096 (bytes, at address 0x40028000 in the strace)
to store the information that's read in.

This is then duplicate-freed with a munmap() towards the end of the strace, 
attempting which causes a segfault.

This is repeatable every time with the user inquestion without the 
aforementioned line in /etc/passwd (although I've made no mention of it, I'm 
also using shadow passwords, but no line in /etc/shadow is required to prevent 
this bug happening, thus implying that it's restricted to the UID->username 
mapping process...).

However, what (possibly) knackers my theory is that it only happens with this 
one user, and not other users with similar setups, on which I'm trying to do 
the same thing...

I've tried making the user that fails have the same user/group config, removing 
trailing slashes from home directory names, etc. all sorts of minor tweaks of 
both the frontpage and the nss-mysql side that might be different between 
working an non-working users, but the only one that works is the line in 
/etc/passwd with the right uid/gid/username.

More information is available on request, although I would like to maintain as 
much customer-information privacy as possible, obviously...

Hopefully someone can help with this, as it defeats the object of having 
nss-mysql in the first place if I still need users in /etc/password :(

K.

PS. With debug enabled, when I get the above segfault, I only get this in my 
logs:

Jun 26 02:31:38 lestat nss-mysql[560]: getpwuid called for 1004
Jun 26 02:31:38 lestat owsadm.exe[560]: _nss_mysql_read_conf_file: called for 
section users
Jun 26 02:31:38 lestat owsadm.exe[560]: _nss_mysql_read_conf_file ended for 
section users

Oh, and it's nss-mysql-0.37.1 ;-)

Follow-up Comments
*******************

-------------------------------------------------------
Date: 2003-Feb-20 11:03             By: gmorin
Great! Thanks for telling me.

Guillaume.

-------------------------------------------------------
Date: 2003-Feb-20 10:53             By: kyrian
Guillaume,

After having - under less than ideal circumstances, to say the least - been 
forced to upgrade the machine that's exhibiting this problem to the latest 
version of RedHat, I'm sure you'll be happy to hear that this bug seems to have 
gone away completely.

K.

-------------------------------------------------------
Date: 2002-Sep-15 19:22             By: gmorin
Hi,

Here is the ldd ouput on my nss-mysql installation :

libz.so.1 => /usr/lib/libz.so.1 (0x6ffa5000)
libpthread.so.0 => /lib/libpthread.so.0 (0x6ff6f000)
libmysqlclient_r.so.10 => /usr/lib/libmysqlclient_r.so.10 (0x6ff10000)
libc.so.6 => /lib/libc.so.6 (0x6fdb5000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x6fd69000)
libnsl.so.1 => /lib/libnsl.so.1 (0x6fd33000)
libm.so.6 => /lib/libm.so.6 (0x6fc9c000)

I do not think there is a "working set of libs". nss-mysql only depends on 
libmysqlclient. I've run nss-mysql compiled against libmysqlclient.so.9 for 
months. The only time I saw a similar problem I had to recompile the php module 
against the same version of libmysqlclient. I know I already told you, but  
that is the only explanation I have. Every app that uses dynamically loaded 
modules (not shared libs) may induce that kind of problem. The bad thing is I 
really cannot see how you could diagnose the problem. Maybe removing temporariy 
libmysqlclient.so.9 to see which app relies on it and if you can recompile it 
against libmysqlclient.so.10.

Maybe I am missing something but I really can't see what ...

HTH.

Guillaume.

-------------------------------------------------------
Date: 2002-Sep-15 18:24             By: kyrian
I just did that, forced it to be compiled against libmysqlclient.so.9.0.0, and 
I still get the same problem.

When compiled against that library, here's the output from ldd:

/usr/lib/libnss_mysql.so:
        libz.so.1 => /usr/lib/libz.so.1 (0x40013000)
        libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40021000)
        libmysqlclient.so.9 => /usr/lib/mysql/libmysqlclient.so.9 (0x40036000)
        libc.so.6 => /lib/i686/libc.so.6 (0x40067000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x40197000)
        libm.so.6 => /lib/i686/libm.so.6 (0x401ae000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x401d2000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

Maybe a comparison against a known-working set of libraries would help?

K.

-------------------------------------------------------
Date: 2002-Sep-15 13:22             By: gmorin
Hmm, I read again my last post. It was quite unclear. Here is a more 
understandable explanation :

There is a link "libmysqlclient.so" in /usr/lib. I guess it points to 
libmysqclient.so.10. Make it point to libmysqlclient.so.9 before the 
compilation. nss-mysql should be compiled against libmysqlclient.so.9. Then you 
can point back libmysqlclient.so to libmysqlclient.so.10.

HTH.

Guillaume.

-------------------------------------------------------
Date: 2002-Sep-13 00:35             By: gmorin
Hi,

I will add the version number somewhere in the binary after 0.42.1 release. 
Concerning your question about linking, I think you should just change the 
libmysqlclient.so.

Guillaume.

-------------------------------------------------------
Date: 2002-Sep-12 19:38             By: kyrian
nss-mysql-0.42pre43 tried.

Still the same problem. Segfaults/stops at mysql_init(NULL). Although ordinary 
SSH authentication and stuff all works fine (without a restart of the SSH 
server being necessary).

A few suggestions...

strings /usr/lib/libnss_mysql.so.X doesn't reveal the version number, and I 
don't know of any other way to reveal the currently installed library version, 
how about assigining a global character array which is used to store the 
version information? Thereby ensuring that the version number is visible from 
running strings on the library? Something like that anyway.

Also, I have the legacy libmysqlclient.so.9 installed on my machine, as well as 
libmysqlclient.so.10.

Linking against the .so.10 library is causing problems, but I've not figured 
out how to link against the .so.9 library, as they are both in the same 
directory, and I can see no reference to the library in the Makefile.

I don't understand this new-fangled libtool, automake, and autoconf stuff, 
y'see... :(

Any idea how I can force linking against the .so.9 file?

(MySQL is version 3.23.51, aside from the backward-compatible 
libmysqlclient.so.9...)



-------------------------------------------------------
Date: 2002-Sep-12 18:49             By: gmorin
You need automake 1.4+ and autoconf 2.50+. I am going to send you a tarball via 
email.

Guillaume.

-------------------------------------------------------
Date: 2002-Sep-12 18:09             By: kyrian
Still not got the CVS compiled and working...

Looks like I need to upgrade various bits of software to get the autogen.sh 
script working properly...

address@hidden nss-mysql-cvs-20020910]# ./autogen.sh 
aclocal: couldn't open `configure.in': No such file or directory
autoheader-2.53: `src/config.h.in' is unchanged
libtoolize: `configure.in' does not exist
Try `libtoolize --help' for more information.
automake: couldn't open `configure.in': No such file or directory
address@hidden nss-mysql-cvs-20020910]# 

Any idea what the minimum requirements are?

K.


-------------------------------------------------------
Date: 2002-Sep-12 17:19             By: gmorin
Hi,

Have you had the time to test the CVS ? I am considering to release 0.42.1. I'd 
really like to know if your ssh problem is still there and if it fixes your 
segfault.

Regards,

Guillaume.

-------------------------------------------------------
Date: 2002-Sep-10 16:46             By: gmorin
Hi,

To generate a configure script, you just need to run autogen.sh.

I am really astonished by your ssh problem. Numerous people run nss-mysql with 
sshd, so far no one has reported such problems. As you've pointed out, there is 
no errors in the log. Very very weird. Maybe you're just cursed :-)

Have you tried to restart sshd ? Maybe it could help...
When you'll have the CVS version installed, could you tell me if you see any 
changes please ?

Regards, 

Guillaume.

-------------------------------------------------------
Date: 2002-Sep-10 16:39             By: kyrian
I tried the latest CVS, but had an outbreak of brain-death, and forgot how to 
get the latest CVS to configure and make. Doubtless I'll remember soon though.

I did try version 0.42, though, and that would compile and install fine, but it 
failed to authenticate normal users...

I didn't even get as far as to check out this bug occurence.

The nss-mysql library seems to say that the query succeeds, but when ssh-ing 
into the machine with an nss-mysql'ed user, I get the following, and the 
connection gets closed:

Sep 10 15:15:48 lestat nss-mysql[16519]: passwd.c: handle_query called for name 
XXX, uid 0, bulk 0
Sep 10 15:15:48 lestat nss-mysql[16519]: _nss_mysql_read_conf_file: called for 
section users
Sep 10 15:15:48 lestat nss-mysql[16519]: _nss_mysql_read_conf_file ended for 
section users
Sep 10 15:15:48 lestat nss-mysql[16519]: _nss_mysql_set_fork_handler: called
Sep 10 15:15:48 lestat nss-mysql[16519]: _nss_mysql_set_fork_handler: finished
Sep 10 15:15:48 lestat nss-mysql[16519]: _nss_mysql_check_connection called
Sep 10 15:15:48 lestat nss-mysql[16519]: _nss_mysql_check_connection: found a 
saved MYSQL * (0x80ebf40)
Sep 10 15:15:48 lestat nss-mysql[16519]: _nss_mysql_check_connection: pinging 
0x80ebf40
Sep 10 15:15:48 lestat nss-mysql[16519]: _nss_mysql_check_connection: 
sucessfully exiting
Sep 10 15:15:48 lestat nss-mysql[16519]: passwd.c: get_query called for user XXX
Sep 10 15:15:48 lestat nss-mysql[16519]: _nss_mysql_escape_string: escaping 
"XXX" (*call_free == 0)
Sep 10 15:15:48 lestat nss-mysql[16519]: passwd.c: get_query: SQL statement is 
select 
users.user_name,users.uid,NULL,users.realname,users.shell,users.home,users.gid 
from users where users.user_name='XXX' and users.uid is not null and 
users.status = 'A' order by users.uid
Sep 10 15:15:48 lestat nss-mysql[16519]: _nss_mysql_send_query:called. MYSQL * 0
x80ebf40, mutex 0x403f78f0, SQL statement: select 
users.user_name,users.uid,NULL,users.realname,users.shell,users.home,users.gid 
from users where users.user_name='XXX' and users.uid is not null and 
users.status = 'A' order by users.uid

[ ... loads of nss_mysql_copy_to_buffer() for appropriate values removed for 
user privacy/security, prior ones XXX'd out ... ]

Sep 10 15:15:49 lestat nss-mysql[16519]: _nss_mysql_passwd_result_to_struct 
finished sucessfully
Sep 10 15:15:49 lestat nss-mysql[16519]: passwd.c: leaving handle_query with 
status 1 (errno Success)

Should I submit the errors I got in config.log when compiling 0.42 as well?

K.

-------------------------------------------------------
Date: 2002-Sep-10 15:56             By: gmorin
Hi,

Could you try the latest CVS and tell me if it fixes your problem please ?

Regards,

Guillaume.

-------------------------------------------------------
Date: 2002-Sep-05 16:13             By: gmorin
Hi,

Yes the bug is still there. The other user was running the MySQL official 
binaries on a Debian x86.

Please tell me when you had time to properly upgrade your box, if it fixed the 
problem.

Regards,

Guillaume.

-------------------------------------------------------
Date: 2002-Sep-03 17:39             By: kyrian
Guillaume,

Now with MySQL 3.23.51, and nss-mysql 0.41...

Sep  3 15:49:26 lestat nss-mysql[29806]: getent(1) exited with status 0
Sep  3 15:49:26 lestat nss-mysql[29806]: endent called for group(1)
Sep  3 15:49:26 lestat nss-mysql[29806]: endent(1) finished
Sep  3 15:49:26 lestat nss-mysql[29806]: getpwuid called for 1004
Sep  3 15:49:26 lestat nss-mysql[29806]: _nss_mysql_read_conf_file: called for 
section users
Sep  3 15:49:26 lestat nss-mysql[29806]: _nss_mysql_read_conf_file ended for 
section users
Sep  3 15:49:26 lestat nss-mysql[29806]: _nss_mysql_check_connection called
Sep  3 15:49:26 lestat nss-mysql[29806]: _nss_mysql_check_connection: 
Initiating a new connection
Sep  3 15:49:26 lestat nss-mysql[29806]: _nss_mysql_db_connect: called
Sep  3 15:49:26 lestat nss-mysql[29806]: _nss_mysql_db_connect: calling 
mysql_init(NULL)

Which I assume is the same problem...

Do you know what architecture the other person with similar problems is running?

Although, having said all this, I'm still running an old version of RedHat's 
mysqlclient9 which is most likely to mean that I've not upgraded the necessary 
library.

My only option, it would appear is to upgrade my entire server (which is 
currently rather a mish-mash of various redhat versions) to the latest RedHat 
versions, at which point I presume it will all start working fine.

I'll try and note down the applicable differences if I possibly can, so that 
this can be added to some nss-mysql documentation if needs be.



-------------------------------------------------------
Date: 2002-Sep-03 14:57             By: gmorin
Hi Kyrian,

I've just wanted to know if you still have that problem. An user which reported 
a similar segfault has fixed it by upgrading its mysql binaries to 3.23.51. 
Maybe it could help. You could also to give 0.41 (or latest CVS) a try.

Regards,

Guillaume.

-------------------------------------------------------
Date: 2002-Jul-25 18:30             By: gmorin
Kyrian,

Do you have any news about this bug ?

Regards,

Guillaume.

-------------------------------------------------------
Date: 2002-Jul-05 21:24             By: kyrian
I only have php4 installed.

ldd /etc/httpd/modules/libphp4.so yields no reference to libmysqlclient.so.X

It's a similar story for all of the other apache modules that I have...

but ldd /usr/lib/php4/mysql.so yields a reference to that, only it's 
libmysqlclient.so.10, just like everything else.

I'll have a look and see if I can find anything else that might be linked 
against the wrong libraries...

K.


-------------------------------------------------------
Date: 2002-Jul-05 21:06             By: gmorin
Hi,

Hmm I had exactly the same problem some time ago. I experienced some weird 
crashes too in the same functions. It was because my mysql php3 module was 
linked again libmysqlclient.so.9 and nss-mysql to libmysqlclient.so.10.
I recompiled php and it fixed the crash.

Could you try that ?

Guillaume.

-------------------------------------------------------
Date: 2002-Jul-05 19:45             By: kyrian
Guillaume,

Okay. In order to try and track this down, I recompiled nss-mysql (latest CVS) 
with some additional calls to _nss_mysql_log() in sensible places within lib.c 
and passwd.c

Using that method, I've tracked it down to lib.c, line 212, or there abouts, 
the call to:

 mysql_init(NULL);

Which causes a segfault.

Even replacing mysql_init(NULL) with mysql_init(tmp) [ tmp having been 
previously allocated(or was that just a pointer, and not an end structure?), 
also causes the same problem, so there seems to be little choice left but to 
blame the MySQL libraries themselves...

Although as a thought, I have both libmysqlclient.so.9, and 
libmysqlclient.so.10 installed, which might be a cause of problems at some 
stage?

The nss_mysql library is linked against libmysqlclient.so.10, as is my "mysql" 
command line client program, which works fine.

Curiouser and curiouser...

Although (and I should have mentioned this earlier no doubt), maybe this is 
related to the fact that I keep getting loads of messages thusly in my logs 
(about two per minute):

Aborted connection to db: 'xxxx' user: 'xxxx' host: 'localhost' (Got an error 
reading communication packets)

And MySQL is running out of connections and for some reason doesn't deal with 
it properly when mysql_init() is called... hence the crash?

K.

-------------------------------------------------------
Date: 2002-Jul-05 17:52             By: kyrian
Guillaume,

> This is very weird.
Yep :(

> All log entries you've given are completely normal.
> I really have no idea of what is going on.
I just looked at that strace again, and it's not because of a duplicate 
munmap(). The same address appears multiple times because it's reallocated 
multiple times, which is normal.

However I'm surprised to see that it crashes right after deallocating the 
buffer used to read /etc/nss-mysql.conf, and /etc/nsswitch.conf, rather than 
the strace/ltrace showing it crashing during a call to libmysqlclient.so.X...

I'd assumed it wasn't do do with the MySQL libraries as a result, and a problem 
was occuring before this happened.

> The frontpage extension is an apache module, right ?
Yes.

The source of it is available here: http://people.freebsd.org/~mbr/distfiles/

> If so, do you use any MySQL related modules with
> apache (like php4 with MySQL support) ?
I have PHP3 with MySQL support enabled in the server as a DSO, yes.

But the trouble with that theory is that the owsadm.exe program also crashes, 
and that program doesn't go anywhere near the apache executable, so I don't 
think it's apache related.

I'll have a look some more.

K.

-------------------------------------------------------
Date: 2002-Jul-05 16:57             By: gmorin
Hi,

This is very weird. All log entries you've given are completely normal.I really 
have no idea of what is going on.
The frontpage extension is an apache module, right ? If so,
do you use any MySQL related modules with apache (like php4 with MySQL support) 
?

TIA.

Guillaume.

-------------------------------------------------------
Date: 2002-Jul-04 19:30             By: kyrian
Running the CVS version, I get the same as above.

Aside from that the log message now shows as:

<date> nss-mysql[<pid>]: _nss_mysql_read_conf_file: etc...

[ excuse the abbreviation... ]

and that it now shows the following immediately after the above (don't know if 
it's related):

<date> nss-mysql[<pid>]: check_connection: opening a connection.

This is assuming that the owsadm program doesn't do a fork() and get a 
different PID, as I've only taken the entries with the same PID into 
consideration.

In case it does fork(), there's a series of these messages before the above, 
with a similar PID [which might indicate that it did fork() ]

<date> nss-mysql[<pid2>]: endent called for passwd(0)
<date> nss-mysql[<pid2>]: endend(0): ent was NULL
<date> nss-mysql[<pid2>]: endend(0) finished

That appears about 25 times under 1 pid, and once under a 3rd unique pid, prior 
to the above messages. May or may not be related.

K.

-------------------------------------------------------
Date: 2002-Jul-04 18:37             By: kyrian
An ltrace of the command which causes the segfault shows no extra information 
(beyond what is normally output by that command), so I assume that this must 
mean that it has been statically linked?

I'll get to trying it with the latest CVS shortly...


-------------------------------------------------------
Date: 2002-Jul-04 15:32             By: gmorin
Hi,

Sorry for the late response, the bug email notification did not work :-(. It 
should work now.

Could you try  to reproduce that problem with current CVS and
send me the debug log ?

I'd like to know if the frontpage software is linked dynamically with the mysql 
libraries too.

Could you try to run ltrace on the process when reproducing the bug, that would 
be helpful ?

Regards,

Guillaume.

-------------------------------------------------------
Date: 2002-Jun-28 09:50             By: kyrian
Hmmm... After a thought struck me, I tried changing the working user's username 
to the same length as the non-working one.

Lo and behold, I began to get segfaults on certain operations from the formerly 
working user when I made its username seven characters long (as opposed to its 
original four).

Maybe it has something to do with it, maybe not...



CC list is empty


File Attachments
****************

-------------------------------------------------------
Date: 2002-Jun-26 04:44  Name: crud  Size: 8KB   By: kyrian
strace of bug.
http://savannah.nongnu.org/bugs/download.php?group_id=443&amp;bug_id=757&amp;bug_file_id=42


For detailed info, follow this link:
http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=757&group_id=443




reply via email to

[Prev in Thread] Current Thread [Next in Thread]