> There is one more improbable thing I can think of: comcom. This is > dosemu's built-in command.com and uses some very tricky code > (coopthreads), which certainly does not work any more with address space > randomization. It's deprecated but was still present in 1.2.2, and Debian > packages still used it with dosemu 1.2.1. The fix for that one is easy: > replace your command.com with a real DOS command.com (e.g. FreeDOS > freecom).
#define STACK_GRAN_SHIFT 17 /* 128K address space granularity */ #define STACK_GRAN (1U << STACK_GRAN_SHIFT) #define STACK_TOP 0xc0000000U #define STACK_BOTTOM 0xa0000000U #define STACK_TOP_PADDING STACK_GRAN #define STACK_SLOTS ((STACK_TOP-STACK_BOTTOM) >> STACK_GRAN_SHIFT) #define roundup_stacksize(size) ((size + STACK_GRAN - 1) & (-((int)STACK_GRAN))) that certainly isn't boding well for things.... ok this thing is evil. It hardcode assumes that the stack goes from 0xc00000 to 0xa0000000, divides it into slots of 128Kb and uses each such slot for a thread. With the randomisation there may be "slots" above the actual stack that appear free but are just entirely unmapped. This thing is broken beyond belief! (and it won't work for any other kind of split than 3:1, eg 2:2 or 4:4 or 0.5:3.5, as well as the 4Gig address space on x86-64 or ia64 in 32 bit emu mode) I can't think of any reasonable way to work around this behavior other than suggesting to use the setarch option to disable randomisation for this process... this is just too much weirdness/brokenness to work around. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
