malloc errors, HUGE stack

Hi, I'm still hunting my "Could not allocate" bugs. I switched to Linux
hoping they would go away, but they didn't. So no I put a sleep(60) into
emalloc() afetr it prints this bug.   Please notice that this nessusd
compiled with -O0 and statically linked against libnessus and libnasl.
Version is 2.0.10a.

 First thing I noticed was that I have a HUGE stacktrace:
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x402ca580 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0x402ca3d8 in sleep () from /lib/tls/i686/cmov/libc.so.6
#3  0x08068bf1 in emalloc (size=167772371) at system.c:72
#4  0x0807e113 in nasl_recv (lexic=0x82b2450) at nasl_socket.c:353
#5  0x08078f4f in nasl_func_call (lexic=0x82b7750, f=0x8293828,
arg_list=0x8247038) at nasl_func.c:283
#6  0x08076aa6 in nasl_exec (lexic=0x82b7750, st=0x82471e0) at exec.
c:1034
#7  0x08074de3 in cell2atom (lexic=0x82b7750, c1=0x82471e0) at exec.
c:248
#8  0x08078d55 in nasl_func_call (lexic=0x82b7750, f=0x8293f60,
arg_list=0x8246fb8) at nasl_func.c:227
#9  0x08076aa6 in nasl_exec (lexic=0x82b7750, st=0x8247230) at exec.
c:1034
#10 0x08076c1b in nasl_exec (lexic=0x82b7750, st=0x8247258) at exec.
c:1091
#11 0x080765d9 in nasl_exec (lexic=0x82b7750, st=0x8247390) at exec.
c:845
#12 0x08076628 in nasl_exec (lexic=0x82b7750, st=0x82473b8) at exec.
c:853
#13 0x08076628 in nasl_exec (lexic=0x82b7750, st=0x82473e0) at exec.
c:853
#14 0x080767ef in nasl_exec (lexic=0x82b7750, st=0x8247408) at exec.
c:923
#15 0x08076628 in nasl_exec (lexic=0x82b7750, st=0x8247430) at exec.
c:853
#16 0x08076628 in nasl_exec (lexic=0x82b7750, st=0x8247458) at exec.
c:853
#17 0x0807657c in nasl_exec (lexic=0x82b7750, st=0x8247480) at exec.
c:835
#18 0x080765d9 in nasl_exec (lexic=0x82b7750, st=0x8248568) at exec.
c:845
#19 0x08076628 in nasl_exec (lexic=0x82b7750, st=0x8248590) at exec.
c:853
#20 0x08076628 in nasl_exec (lexic=0x82b7750, st=0x82485b8) at exec.
c:853
#21 0x08076628 in nasl_exec (lexic=0x82b7750, st=0x82485e0) at exec.
c:853
#22 0x08076628 in nasl_exec (lexic=0x82b7750, st=0x8248608) at exec.
c:853
#23 0x08076628 in nasl_exec (lexic=0x82b7750, st=0x8248630) at exec.
c:853
#24 0x08076628 in nasl_exec (lexic=0x82b7750, st=0x8248658) at exec.
c:853
#25 0x08076628 in nasl_exec (lexic=0x82b7750, st=0x8248680) at exec.
c:853
#26 0x08078f69 in nasl_func_call (lexic=0x82a0a98, f=0x8295c30,
arg_list=0x8249af0) at nasl_func.c:287
#27 0x08076aa6 in nasl_exec (lexic=0x82a0a98, st=0x8249be8) at exec.
c:1034
#28 0x08076c1b in nasl_exec (lexic=0x82a0a98, st=0x8249c10) at exec.
c:1091
#29 0x080765d9 in nasl_exec (lexic=0x82a0a98, st=0x8249d58) at exec.
c:845
#30 0x08076628 in nasl_exec (lexic=0x82a0a98, st=0x8249d80) at exec.
c:853
#31 0x08076628 in nasl_exec (lexic=0x82a0a98, st=0x8249da8) at exec.
c:853
#32 0x08078f69 in nasl_func_call (lexic=0x829f960, f=0x8295cb8,
arg_list=0x824ea38) at nasl_func.c:287
#33 0x08076aa6 in nasl_exec (lexic=0x829f960, st=0x824ea60) at exec.
c:1034
#34 0x08076c1b in nasl_exec (lexic=0x829f960, st=0x824ea88) at exec.
c:1091
#35 0x080765d9 in nasl_exec (lexic=0x829f960, st=0x824fab8) at exec.
c:845
....
#810 0x08076628 in nasl_exec (lexic=0x8292e28, st=0x8292d10) at exec.
c:853
#811 0x08076628 in nasl_exec (lexic=0x8292e28, st=0x8292d38) at exec.
c:853
#812 0x08076628 in nasl_exec (lexic=0x8292e28, st=0x8292d60) at exec.
c:853
#813 0x08076628 in nasl_exec (lexic=0x8292e28, st=0x8292d88) at exec.
c:853
#814 0x08076628 in nasl_exec (lexic=0x8292e28, st=0x8292db0) at exec.
c:853
#815 0x08076628 in nasl_exec (lexic=0x8292e28, st=0x8292dd8) at exec.
c:853
#816 0x08076628 in nasl_exec (lexic=0x8292e28, st=0x8292e00) at exec.
c:853
#817 0x080785a5 in execute_nasl_script (script_infos=0x80fb228,
name=0x823bf20 "/usr/lib/nessus/plugins/DDI_Directory_Scanner.nasl",
mode=0) at exec.c:1740
#818 0x0805b8e0 in nasl_thread (g_args=0x823bd18) at nasl_plugins.c:214
#819 0x08054c5d in create_process (function=0x805b6e3 <nasl_thread>,
argument=0x823bd18) at processes.c:108
#820 0x0805b6d0 in nasl_plugin_launch (globals=0x81a9b10,
plugin=0x80fb228, hostinfos=0x8228a68, preferences=0x80ec2f0,
kb=0x8239bc0,
    name=0x823bf20 "/usr/lib/nessus/plugins/DDI_Directory_Scanner.nasl",
soc=9) at nasl_plugins.c:156
#821 0x08063499 in plugin_launch (globals=0x81a9b10, plugin=0x81a3eb0,
hostinfos=0x8228a68, preferences=0x80ec2f0, key=0x8239bc0,
    name=0x823bf20 "/usr/lib/nessus/plugins/DDI_Directory_Scanner.nasl",
launcher=0x809c900) at pluginlaunch.c:503
#822 0x080510b9 in launch_plugin (globals=0x81a9b10, plugins=0x81a3eb0,
hostname=0xbfffee08 "XX.XX.XX.XX", cur_plug=0xbfffed30, num_plugs=2062,
hostinfos=0x8228a68,
    key=0x8239bc0, new_kb=1) at attack.c:271
#823 0x0805144d in attack_host (globals=0x81a9b10, hostinfos=0x8228a68,
hostname=0xbfffee08 "XX.XX.XX.XX", sched=0x81d3698) at attack.c:423
#824 0x080516f9 in attack_start (args=0xbfffedf0) at attack.c:524
#825 0x08054c5d in create_process (function=0x80514e9 <attack_start>,
argument=0xbfffedf0) at processes.c:108
#826 0x080522a5 in attack_network (globals=0x81a9b10) at attack.c:820
#827 0x0805d08f in server_thread (globals=0x81a9b10) at nessusd.c:526
#828 0x08054c5d in create_process (function=0x805ca8d <server_thread>,
argument=0x81a9b10) at processes.c:108
#829 0x0805d891 in main_loop () at nessusd.c:860
#830 0x0805e4c1 in main (argc=2, argv=0xbffffdb4, envp=0xbffffdc0) at
nessusd.c:1318

Is this really intended?

Looking at the data in gdb, the len comes from the length parameter of
"nasl_recv".  Is there any smart way to find out which nasl_recv of
DDI_Directory_Scanner.nasl is processed at this stage?

--nk

_______________________________________________
Nessus-devel mailing list
[email protected]
http://mail.nessus.org/mailman/listinfo/nessus-devel