View Issue Details

IDProjectCategoryView StatusLast Update
0000495LDMudRuntimepublic2018-01-29 21:57
ReporterGnomi Assigned Tolars 
PrioritynormalSeveritycrashReproducibilitysometimes
Status resolvedResolutionfixed 
Platformi686OSDebian GNU/LinuxOS Version3.1
Summary0000495: Errors during setup_new_frame may crash the driver
DescriptionThe following program crashes the driver:

void fun(varargs mixed* arg) {}

void create()
{
    int x;
    
    funcall(#'fun, &x);
}

Program received signal SIGSEGV, Segmentation fault.
0x08060be7 in closure_location (l=0x8b3b287) at closure.c:5653
(tgdb) bt
#0 0x08060be7 in closure_location (l=0x8b3b287) at closure.c:5653
0000001 0x080b08d5 in get_line_number_if_any (name=0xbfb9a5dc) at interpret.c:18552
0000002 0x0810914c in errorf (fmt=0xbfb99ddc "Varargs argument passed by reference.\n") at simulate.c:896
0000003 0x08092cd7 in setup_new_frame2 (funstart=0x92adb6c "\201", sp=0x81743b8, allowRefs=0, is_lambda=0) at interpret.c:7162
0000004 0x080929f0 in setup_new_frame (fx=0, inhProg=0x0) at interpret.c:7301
0000005 0x080af4f5 in int_call_lambda (lsvp=0x81743b0, num_arg=1, allowRefs=0) at interpret.c:17765
0000006 0x080b3e8a in v_funcall (sp=0x81743b8, num_arg=2) at interpret.c:20261
0000007 0x080953cd in eval_instruction (first_instruction=0x92adb7e "`", initial_sp=0x81743a0) at interpret.c:8173
0000008 0x080adc6d in apply_low (fun=0x8b23978, ob=0x92eadf0, num_arg=0, b_ign_prot=0, allowRefs=0) at interpret.c:16811
0000009 0x080ade64 in int_apply (fun=0x8b23978, ob=0x92eadf0, num_arg=0, b_ign_prot=0, b_use_default=1) at interpret.c:16889
0000010 0x080a8e2a in eval_instruction (first_instruction=0x8b1efbb "a\036", initial_sp=0x8174380) at interpret.c:16159
0000011 0x080af893 in int_call_lambda (lsvp=0x823e348, num_arg=1, allowRefs=0) at interpret.c:17893
0000012 0x080d00f9 in reset_object (ob=0x92eadf0, arg=5) at object.c:868
0000013 0x0810ba94 in load_object (lname=0x81f98e0 "w/gnomi/snf", create_super=0, depth=0, isMasterObj=0, chain=0x0) at simulate.c:2132
#14 0x0810c372 in lookfor_object (str=0x9217fd4, bLoad=1) at simulate.c:2397
#15 0x0810fc8b in f_load_object (sp=0x8174370) at simulate.c:4466
#16 0x08094222 in eval_instruction (first_instruction=0x8b4abd6 "\036\001\003P\036", initial_sp=0x8174368) at interpret.c:7974
#17 0x080af547 in int_call_lambda (lsvp=0x8174358, num_arg=2, allowRefs=0) at interpret.c:17772
#18 0x080b3e8a in v_funcall (sp=0x8174368, num_arg=3) at interpret.c:20261
#19 0x080953cd in eval_instruction (first_instruction=0x8b4abee "`\002\005\036", initial_sp=0x8174348) at interpret.c:8173
#20 0x080a622e in eval_instruction (first_instruction=0x92bc18e "a\017\003@\036", initial_sp=0x8174308) at interpret.c:14664
#21 0x080adc6d in apply_low (fun=0x9259f60, ob=0x929872c, num_arg=1, b_ign_prot=0, allowRefs=0) at interpret.c:16811
#22 0x080ade64 in int_apply (fun=0x9259f60, ob=0x929872c, num_arg=1, b_ign_prot=0, b_use_default=1) at interpret.c:16889
#23 0x080ae2ce in sapply_int (fun=0x9259f60, ob=0x929872c, num_arg=1, b_find_static=0, b_use_default=1) at interpret.c:17050
#24 0x0804c9ce in parse_command (buff=0xbfb9e2c0 "lade snf", from_efun=0) at actions.c:1094
#25 0x0804cf41 in execute_command (str=0xbfb9e2c0 "lade snf", ob=0x920e1b4) at actions.c:1258
#26 0x08054999 in backend () at backend.c:671
#27 0x080c02c9 in main (argc=20, argv=0xbfb9fc74) at main.c:615

The reason is that the current csp is not yet fully initialized (especially csp->funstart is missing). That's why int_call_lambda does a CLEAN_CSP before an error, but setup_new_frame, setup_new_frame2 and other functions like stack_overflow or allocate_array, which are called from within int_call_lambda, do not.

In the above example the call to #'fun raises the error 'Varargs argument passed by reference.', so errorf() wants to get the current line number and inspects csp->funstart, but as this may be some arbitrary value further inspection results in a segfault.

Greetings,
Gnomi.
TagsNo tags attached.
External Data (URL)

Activities

lars

2007-10-14 00:04

reporter   ~0000569

Cleaining the CSP in setup_new_frame() would mean that funcall(#'fun, &x) and fun(&x) would deliver differing stack traces.

The solution I chose was to update the csp->funstart inside of setup_new_frame(), just before setup_new_frame2() is called. Putting that into setup_new_frame() is more convenient for the callers anyway.

Issue History

Date Modified Username Field Change
2006-12-12 07:20 Gnomi New Issue
2007-10-14 00:04 lars Status new => resolved
2007-10-14 00:04 lars Fixed in Version => 3.3.716
2007-10-14 00:04 lars Resolution open => fixed
2007-10-14 00:04 lars Assigned To => lars
2007-10-14 00:04 lars Note Added: 0000569
2010-11-16 09:42 lars Source_changeset_attached => ldmud.git master 432a56e5
2010-11-16 09:42 lars Source_changeset_attached => ldmud.git master-3.2 a920a90b
2018-01-29 18:59 lars Source_changeset_attached => ldmud.git master 432a56e5
2018-01-29 18:59 lars Source_changeset_attached => ldmud.git master-3.2 a920a90b
2018-01-29 21:57 lars Source_changeset_attached => ldmud.git master 432a56e5
2018-01-29 21:57 lars Source_changeset_attached => ldmud.git master-3.2 a920a90b