[ ssic-linux-Bugs-1764324 ] Badness in sk_del_node_init at include/net/sock.h:343

"SourceForge.net" <[email protected]>
Newsgroups gmane.linux.cluster.ssic.devel
Message-ID <[email protected]>
Bugs item #1764324, was opened at 2007-07-31 04:27
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=405834&aid=1764324&group_id=32541

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Process Management
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Badness in sk_del_node_init at include/net/sock.h:343

Initial Comment:
Hi,

On debian 1.9.3 when i start up my applications which involve heavy shared memory usage and network usage i constantly get this on the non-init-nodes until they freeze:

Badness in sk_del_node_init at include/net/sock.h:343
 [<c01068be>] dump_stack+0x1e/0x30
 [<c0412de9>] __unix_remove_socket+0x69/0x70
 [<c0413204>] unix_release_sock+0x24/0x300
 [<c041384a>] unix_release+0x3a/0x90
 [<c039bdc9>] sock_release+0x79/0xc0
 [<c039ca44>] sock_close+0x34/0x50
 [<c016c791>] __fput+0x121/0x140
 [<c016c669>] fput+0x19/0x20
 [<c016acf7>] filp_close+0x57/0x90
 [<c016ad9e>] sys_close+0x6e/0x90
 [<c010596b>] syscall_call+0x7/0xb


There was someone here http://www.ussg.iu.edu/hypermail/linux/kernel/0411.2/0735.html
had experienced the same on SELinux.

-niklas


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-08-01 22:21

Message:
Logged In: NO 

Hi,

I guess it is an error I get when a process using a socket tries to
migrate, or at least it is related to it somehow.

Easily reproduced on my system but I dont know any easy general way to
reproduce it.

The applications I use consist of perl-scripts controlling daemons that
capture pictures and other daemons analyzing them and writing pictures to
disk. One capturing daemon can easily use a block of 100M shared memory and
the analyzing daemons analyzes the data in the same space.

I will see if there is something I can do on application level, eg. to
have daemons started on different nodes to even out load and then not
allowing migrating. I will also try the 2.6.11 kernel. I just couldnt yet
figure out how to do it but I will soon.


I also get lots of these errors:
kernel: reop_export_path: Can't export unlinked file /SYSV7a6d2001
(deleted)


----------------------------------------------------------------------

Comment By: John Hughes (hughesj)
Date: 2007-07-31 06:08

Message:
Logged In: YES 
user_id=166336
Originator: NO

I assume you're talking about the repository at
www.atlantech.com/~john/openssi-debian-1.9.3?

Could you try with the 2.6.11 kernel?

You say "heavy shared memory usage and network usage" any way of
quantifying that?

Any simple recepie for duplicating the problem?



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-07-31 05:58

Message:
Logged In: NO 

Hi,

Made some more research. This comes when a process tries to migrate and
sometimes it comes in relation to 
reop_export_path: Can't export unlinked file /SYSV6d2012 (deleted)


This is on debian sarge, openssi 1.9.3 debs, kernel 2.6.10

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=405834&aid=1764324&group_id=32541

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.