1473384791 J * derjohn_mobi ~aj@x590d656b.dyn.telefonica.de 1473385235 Q * derjohn_mob Ping timeout: 480 seconds 1473387509 Q * fstd Read error: Connection reset by peer 1473387512 J * fstd ~fstd@x4e3190a3.dyn.telefonica.de 1473402744 Q * derjohn_mobi Ping timeout: 480 seconds 1473403141 J * Ghislain ~aqueos@adsl1.aqueos.com 1473404007 M * Bertl_oO off to bed now ... have a good one everyone! 1473404009 N * Bertl_oO Bertl_zZ 1473404627 J * derjohn_mobi ~aj@2001:6f8:1337:0:c526:e5df:9ce5:aa53 1473409007 Q * DelTree Server closed connection 1473409008 J * DelTree ~deplagne@2a00:c70:1:213:246:56:18:2 1473410890 J * marcfiu ~oftc-webi@pool-173-72-20-147.cmdnnj.fios.verizon.net 1473410931 Q * marcfiu 1473413807 J * geos_one ~chatzilla@213-47-170-183.static.upcbusiness.at 1473415427 Q * DoberMann Server closed connection 1473415428 J * DoberMann ~james@2a01:e35:8b44:84c0::2 1473415463 Q * jrayhawk Server closed connection 1473415465 J * jrayhawk ~jrayhawk@nursie.omgwallhack.org 1473418686 J * thierryp ~thierry@2a01:e35:2e2b:e2c0:14ee:a423:8c84:d89a 1473424749 Q * jrklein Server closed connection 1473424880 J * jrklein ~cloud@proxy.dnihost.net 1473428184 N * Bertl_zZ Bertl 1473428186 M * Bertl morning folks! 1473431349 P * geb 1473433614 Q * geos_one Quit: ChatZilla 0.9.92 [Firefox 48.0/20160807140607] 1473433807 J * geb ~geb@mars.gebura.eu.org 1473437092 Q * derjohn_mobi Ping timeout: 480 seconds 1473439365 J * marcfiu ~oftc-webi@pool-173-72-20-147.cmdnnj.fios.verizon.net 1473439373 M * marcfiu hi Berlt 1473439380 M * marcfiu Bertl 1473439393 M * marcfiu sorry we missed each other on Wednesday... 1473439395 M * Bertl hey marcfiu! 1473439419 M * marcfiu let me find the irc log to revisit the stack trace 1473439457 M * marcfiu http://pastebin.com/Rxsv6DB3 1473439518 M * marcfiu As mentioned, my theory is that "grep" read a /proc/XYZ/nsproxy file at the point when the XYZ task was being reaped by the system. 1473439543 M * Bertl do you have the line for proc_pid_nsproxy+0x48/0xf0 ? 1473439553 M * marcfiu I don't right now... 1473439560 M * marcfiu let me see if I can construct that... 1473439573 M * marcfiu likely will take me a few minutes at the very least 1473439587 M * Bertl np, take your time 1473439697 M * marcfiu okay... 1473439698 M * marcfiu thx 1473440312 Q * gnarface Quit: Leaving 1473440971 M * marcfiu Bertl: I just shipped back my dev laptop. I need to pull things from backup on the new laptop I was shipped. So this will take a bit more than a few minutes. 1473441601 M * Bertl np 1473442473 J * gnarface ~gnarface@108-227-52-42.lightspeed.irvnca.sbcglobal.net 1473442651 M * marcfiu just found my ssh keys on backup :) 1473443245 Q * AbyssOne_ Server closed connection 1473443256 J * AbyssOne_ ~jelle3@jbeusen-1-pt.tunnel.tserv26.ber1.ipv6.he.net 1473446186 Q * Defaultti Quit: Quitting. 1473449854 J * derjohn_mobi ~aj@x590d656b.dyn.telefonica.de 1473449975 J * Defaultti defaultti@lakka.kapsi.fi 1473449975 M * marcfiu Bertl: finally got to the point where I have the vmlinux, vmcore, and source code on my new dev laptop 1473450009 M * marcfiu but I have to admit that its been years since I last used gdb to debug a crash dump and I missing some brain muscle memory on what I do next 1473450149 M * marcfiu googling around I figured out i could do "crash /usr/lib/debug/lib/modules/2.6.32-642.1.1.coblitz.x86_64/vmlinux /tmp/vmcore" 1473450156 M * marcfiu look at the backtrace etc. 1473450166 M * marcfiu crash uses gdb under the covers... 1473450178 M * marcfiu now I just need to figure out how to tell it where the kernel source code is 1473451048 M * marcfiu Bertl: as I figured that one cannot really get the precise line number. 1473451081 M * marcfiu proc_pid_nsproxy really is just 2 lines. One that is a seq_printf(...) that technically spans multiple lines. The other being "return 0". 1473451199 M * marcfiu here's what i did 1473451200 M * marcfiu crash> gdb list *0xffffffff8121e418 0xffffffff8121e418 is in proc_pid_nsproxy (fs/proc/array.c:356). 351 task->nsproxy->mnt_ns, 352 (task->nsproxy->mnt_ns == init_task.nsproxy->mnt_ns ? 'I' : '-'), 353 task->nsproxy->pid_ns, 354 (task->nsproxy->pid_ns == init_task.nsproxy->pid_ns ? 'I' : '-'), 355 1473451205 M * marcfiu crap 1473451230 M * marcfiu http://pastebin.com/14p6Uv4B 1473451370 M * marcfiu this is simply showing that it is part of the seq_printf() 1473451388 M * marcfiu as you can see it is accessing task, task->nsproxy, etc. 1473452935 M * Bertl is that a line we add in the Linux-VServer patch you are using? 1473452960 M * Bertl if so, it might help to simply check the nsproxy before dereferencing it 1473455967 M * marcfiu right 1473455970 M * marcfiu yes 1473455985 M * marcfiu proc_pid_nsproxy() is a function provided by the Linux-VServer patch. 1473455992 M * marcfiu Which is why I am here. 1473456029 M * marcfiu And am basically asking whether it makes sense to check if task->nsproxy == NULL 1473456049 M * marcfiu however, it does sort of feel like a race condition... meaning some other processor was destroying that task. 1473456101 M * marcfiu So maybe it is not sufficient to just check if task->nsproxy == NULL, but maybe one needs to obtain a lock first to make sure some other processor code doesn't go off destroying things while we are fiddling with that data structure. 1473458300 Q * marcfiu Ping timeout: 480 seconds 1473464268 Q * Ghislain Quit: Leaving.