* Yuriy Tsibizov <Yuriy.Tsibizov_at_gfk.ru> wrote: > (gdb) bt > #0 0x00000000 in ?? () > #1 0x0804937d in main (argc=3, argv=0xbfbfed44) > at /usr/src/usr.bin/limits/limits.c:341 > (gdb) l > 341 val = resources[rcswhich].func(lc, resources[rcswhich].cap, limits[rcswhich].rlim_cur, limits[rcswhich].rlim_cur); > 342 limits[rcswhich].rlim_cur = resources[rcswhich].func(lc, str, val, val); > 343 /* maximum value overridden by resourcename or resourcename-max */ > 344 sprintf(str, "%s-max", resources[rcswhich].cap); > 345 val = resources[rcswhich].func(lc, resources[rcswhich].cap, limits[rcswhich].rlim_max, limits[rcswhich].rlim_max); > 346 limits[rcswhich].rlim_max = resources[rcswhich].func(lc, str, val, val); > 347 } > 348 } > 349 } > 350 > (gdb) p resources > $1 = {{cap = 0x804adc2 "cputime", func = 0x8048c84 <login_getcaptime>}, { > cap = 0x804adca "filesize", func = 0x8048c34 <login_getcapsize>}, { > cap = 0x804add3 "datasize", func = 0x8048c34 <login_getcapsize>}, { > cap = 0x804addc "stacksize", func = 0x8048c34 <login_getcapsize>}, { > cap = 0x804ade6 "coredumpsize", func = 0x8048c34 <login_getcapsize>},{ > cap = 0x804adf3 "memoryuse", func = 0x8048c34 <login_getcapsize>}, { > cap = 0x804adfd "memorylocked", func = 0x8048c34 <login_getcapsize>},{ > cap = 0x804ae0a "maxproc", func = 0x8048c94 <login_getcapnum>}, { > cap = 0x804ae12 "openfiles", func = 0x8048c94 <login_getcapnum>}, { > cap = 0x804ae1c "sbsize", func = 0x8048c34 <login_getcapsize>}, { > cap = 0x804ae23 "vmemoryuse", func = 0x8048c34 <login_getcapsize>}, { > cap = 0x0, func = 0}} Looks like I introduced this regression when importing MPSAFE TTY. limits(1) dies when RLIMIT_NLIMITS is increased, but the array in limits.c isn't extended (seems to be quite fragile). Can you try the attached patch for limits(1)? Thanks! -- Ed Schouten <ed_at_80386.nl> WWW: http://80386.nl/
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:34 UTC