Re: Tracking down what looks like a memory leak in 2.3.x

Clemens Huebner (clemens.huebner@att.net)
Sat, 26 Jun 1999 00:55:45 -0700


This is a multi-part message in MIME format.
--------------B179429509F57C3D629AF7D4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Jay,

i sent a fix to the list and Linus (for 2.3.3, didn't get included :-(
).

See the attached mail...

Clemens

Jay Thorne wrote:
>
> "M.Brands" wrote:
> >
> > On Sat, Jun 19, 1999 at 11:49:23PM -0700, Jay Thorne allegedly wrote:
> > > processes doesnt seem to free the memory again. How can I look for the
> > > memory? Might it be shared memory areas left around by a bug in the gnome
> > > libraries?? How do you list shm areas?
> >
> > ipcs
> >
> > Mathijs
> [root@home /root]# ipcs -a
>
> ------ Shared Memory Segments --------
> key shmid owner perms bytes nattch status
> 0x00000000 103680 nobody 600 52228 3 dest
> 0x00000000 68865 jay 777 56 0
> 0x00000000 68866 jay 777 800 0
> 0x00000000 68867 jay 777 80 0
>
> ------ Semaphore Arrays --------
> key semid owner perms nsems status
>
> ------ Message Queues --------
> key msqid owner perms used-bytes messages
> 0x00000000 0 root 700 65 0
> 0x00000000 1 root 700 66 0
> Segmentation fault (core dumped)
>
> WTF? Seg fault?
> I built a new ipcs from util-linux 2.9o (the latest, AFAIK)
> and it still seg faults.
> strace ./ipcs
> <....>
> fcntl(3, F_SETFD, FD_CLOEXEC) = 0
> fstat(3, {st_mode=0, st_size=0, ...}) = 0
> mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x4000c000
> read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 857
> close(3) = 0
> munmap(0x4000c000, 4096) = 0
> write(1, "0x00000000 1 root 7"..., 660x00000000 1
> root 700 66 0
> ) = 66
> --- SIGSEGV (Segmentation fault) ---
> +++ killed by SIGSEGV +++
>
> even gdb is not giving me anything useful.
> (gdb) run
> Starting program: /usr/src/redhat/BUILD/util-linux-2.9r/sys-utils/ipcs
>
> ------ Shared Memory Segments --------
> key shmid owner perms bytes nattch status
> 0x00000000 103680 nobody 600 52228 3 dest
> 0x00000000 68865 jay 777 56 0
> 0x00000000 68866 jay 777 800 0
> 0x00000000 68867 jay 777 80 0
>
> ------ Semaphore Arrays --------
> key semid owner perms nsems status
>
> ------ Message Queues --------
> key msqid owner perms used-bytes messages
> 0x00000000 0 root 700 65 0
> 0x00000000 1 root 700 66 0
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xffffffea in ?? ()
> (gdb) bt
> #0 0xffffffea in ?? ()
>
> --
> Jay Thorne The Net Result System Services jay@result.com
> Http://net.result.com
> Zoom 505 Effect page http://net.result.com/~jay
> Zoom 5xx series Patch Database: http://net.result.com/~jay/db.html
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
--------------B179429509F57C3D629AF7D4
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

X-Mozilla-Status2: 00000000
Message-ID: <37523C0E.CEAD1C57@att.net>
Date: Mon, 31 May 1999 00:36:46 -0700
From: Clemens Huebner <clemens.huebner@att.net>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.3.3 i586)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Linux Kernel Mailinglist <linux-kernel@vger.rutgers.edu>,
Linus Torvalds <torvalds@transmeta.com>
Subject: IPC msgctl MSG_STAT broken, fix proposal attached
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

i just joined the list, so i don't know whether someone else already
fixed this:

The message queue changes in 2.3.3 breaks the MSG_STAT function of the
msgctl ipc
userland function (segmentation fault due to buffer flow).

There are two possibilities to fix this:
1) change all userland programs to use the new msqid_ds structure. That
would be a major
hassle and have no real advantages
2) change the kernel to put out the structure with the old offsets.
Since the changed
fields are not copied out anyways, there is no drawback (except for
increasing
kernel source sice.

Clemens

Here's the patch:
diff -ur linux/include/linux/msg.h linux.new/include/linux/msg.h
--- linux/include/linux/msg.h Sat May 15 16:34:43 1999
+++ linux.new/include/linux/msg.h Sat May 29 21:03:42 1999
@@ -27,6 +27,25 @@
__kernel_ipc_pid_t msg_lspid; /* pid of last msgsnd */
__kernel_ipc_pid_t msg_lrpid; /* last receive pid */
};
+/* to keep compatibility with ipc msgctl syscall, keep old msqid_ds
+ struct */
+struct msqid_u_ds
+{
+ struct ipc_perm msg_perm;
+ struct msg *__msg_first;
+ struct msg *__msg_last;
+ __kernel_time_t msg_stime;
+ __kernel_time_t msg_rtime;
+ __kernel_time_t msg_ctime;
+ void *__wwait; /* not transmitted to userland */
+ void *__rwait; /* not transmitted to userland */
+ unsigned short int msg_cbytes;
+ unsigned short int msg_qnum;
+ unsigned short int msg_qbytes;
+ __kernel_ipc_pid_t msg_lspid;
+ __kernel_ipc_pid_t msg_lrpid;
+};
+

/* message buffer for msgsnd and msgrcv calls */
struct msgbuf {
@@ -73,7 +92,7 @@
asmlinkage int sys_msgsnd (int msqid, struct msgbuf *msgp, size_t
msgsz, int ms
gflg);
asmlinkage int sys_msgrcv (int msqid, struct msgbuf *msgp, size_t
msgsz, long m
sgtyp,
int msgflg);
-asmlinkage int sys_msgctl (int msqid, int cmd, struct msqid_ds *buf);
+asmlinkage int sys_msgctl (int msqid, int cmd, struct msqid_u_ds *buf);

#endif /* __KERNEL__ */

diff -ur linux/ipc/msg.c linux.new/ipc/msg.c
--- linux/ipc/msg.c Sat May 29 16:50:49 1999
+++ linux.new/ipc/msg.c Sat May 29 19:41:39 1999
@@ -352,11 +352,11 @@
kfree(msq);
}

-asmlinkage int sys_msgctl (int msqid, int cmd, struct msqid_ds *buf)
+asmlinkage int sys_msgctl (int msqid, int cmd, struct msqid_u_ds *buf)
{
int id, err = -EINVAL;
struct msqid_ds *msq;
- struct msqid_ds tbuf;
+ struct msqid_u_ds tbuf;
struct ipc_perm *ipcp;

printk("msgctl: %d %d %p\n",msqid,cmd,buf);

--------------B179429509F57C3D629AF7D4--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/