ikrt_directory_list bug?
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ikarus Scheme |
Fix Committed
|
Medium
|
Abdulaziz Ghuloum |
Bug Description
In ikarus-runtime.c, ikrt_directory_list uses pcb->root1 incase ik_safe_alloc causes a GC which moves your object. But every time it loops, it's leaving the old &bv as the value of pcb->root1, and if the next loop's first ik_safe_alloc causes a GC which then uses the old pcb->root1 value, doesn't this value now point to the location of a now invalid variable? (because the old bv local variable is not valid after its block has finished) If such a GC read or wrote the word at the old &bv, it would be an unintended access. If C does not guarantee the new bv of the next loop will take the place in memory of the old bv, this might cause memory corruption. But maybe it does guarantee that, and so this isn't really a concern?
In other words, I'm thinking this should be done:
=== modified file 'src/ikarus-
--- src/ikarus-
+++ src/ikarus-
@@ -632,7 +632,6 @@
de = readdir(dir);
if(de == NULL){
pcb->root0 = 0;
- pcb->root1 = 0;
ikptr retval = (errno ? ik_errno_to_code() : ac);
return retval;
@@ -644,6 +643,7 @@
memcpy(
pcb->root1 = &bv;
ikptr p = ik_safe_alloc(pcb, pair_size) + pair_tag;
+ pcb->root1 = 0;
ref(p, off_car) = bv;
ref(p, off_cdr) = ac;
ac = p;
Related branches
Changed in ikarus: | |
milestone: | none → 0.0.4 |
You're absolutely right here. Fixed in 1580.