[Yhc] Patch: 'Fix reading from past the end of G_markTable in mkt_firstMarked ()'

Tom Shackell shackell at cs.york.ac.uk
Thu Mar 23 09:07:36 EST 2006


Hi Michal,

Oh okay, the constant table is a table of constants that are used by a 
function. For example when a MK_AP is performed it says which function 
to make an application to by using an index into the constant table.

These have to be malloced because you don't know what's in them, or how 
big they need to be, until the bytecode is loaded. However, a function 
can indeed have no constants (although it's fairly uncommon). Easiest 
way is just to add a check before that malloc.


Thanks

Tom


Michał Pałka wrote:
> Neil,
> 
> Attached. I think they are 'sometimes zero'. I hope the stack trace
> makes it clear to you what happens, as it's almost clear to me.
> 
> This looks like allocating ConstTable of size 0. But what is ConstTable
> anyway (are we allocating constants in tables - why?)?
> 
> I'm not telling that calling malloc (0) is inherently bad. As you can
> see, malloc allows this. Electric Fence bails out when it sees malloc
> (0), but this particular check could be turned off. It all depends on
> your policy, whether you allow 0-mallocs or not.
> 
> A heavy-weight approach to sorting this out came to my mind. You define:
> void* zmalloc (size_t n)
> {
> 	if (n != 0) return malloc (n);
> 	return NULL;
> }
> 
> void* nzmalloc (size_t n)
> {
> 	assert (n != 0);
> 	return malloc (n);
> }
> And use one of them depending on what you expect n to be. But wrapping
> some mallocs in if (n != 0) {} is also ok IMO.
> 
> Thanks,
> Michal
> 
> On Tue, 2006-03-21 at 14:30 +0000, Neil Mitchell wrote:
> 
>>Hi Michal,
>>
>>Any chance you can send an example of one of these 0-sized mallocs?
>>Are they always zero, normally zero or what?
>>
>>In general though, it would be nice to have Yhc work perfectly (i.e.
>>no warnings) with these tools, so its easier to detect real problems,
>>so I'd have thought the answer was yes, these need fixing.
>>
>>Thanks
>>
>>Neil
>>
>>On 3/20/06, Michał Pałka <michal.palka at poczta.fm> wrote:
>>
>>>I discovered this using Valgrind and Electric Fence. There are also
>>>mallocs of size 0 that are considered errors by efence. Should I attempt
>>>to fix them?
>>>
>>>Michal
>>>
>>>
>>>_______________________________________________
>>>Yhc mailing list
>>>Yhc at haskell.org
>>>http://haskell.org/mailman/listinfo/yhc
>>>
>>>
>>>
>>>
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>#0  0x00002aaaab1d0189 in kill () from /lib/libc.so.6
>>>#1  0x00002aaaaabc5053 in EF_Abort () from /usr/lib/libefence.so.0.0
>>>#2  0x00002aaaaabc4c04 in memalign () from /usr/lib/libefence.so.0.0
>>>#3  0x00002aaaaabc4c97 in malloc () from /usr/lib/libefence.so.0.0
>>>#4  0x0000000000402c98 in mod_loadConstTable (mod=0x2aaaab42efb8, finfo=0x2aaab0a12fb8) at module.c:272
>>>#5  0x0000000000403a4b in mod_loadFun (mod=0x2aaaab42efb8, name=0x2aaab0a14fe4 "Prelude.Num.Prelude.Int.-", obj=0x2aaab0a0cff0)
>>>    at module.c:439
>>>#6  0x0000000000403cb4 in mod_loadObject (mod=0x2aaaab42efb8, offs=117594, obj=0x2aaab0a0cff0) at module.c:514
>>>#7  0x0000000000402a13 in mod_resolve (module=0x2aaab0a0eff8 "Prelude", item=0x2aaab0a10fe4 "Prelude.Num.Prelude.Int.-") at module.c:209
>>>#8  0x0000000000402f0d in mod_loadConstTable (mod=0x2aaab089cfb8, finfo=0x2aaab0997fb8) at module.c:322
>>>#9  0x0000000000403a4b in mod_loadFun (mod=0x2aaab089cfb8, name=0x2aaab0999ff8 "valid", obj=0x2aaab0991ff0) at module.c:439
>>>#10 0x0000000000403cb4 in mod_loadObject (mod=0x2aaab089cfb8, offs=1475, obj=0x2aaab0991ff0) at module.c:514
>>>#11 0x0000000000402a13 in mod_resolve (module=0x2aaab0993ff8 "Main", item=0x2aaab0995ff8 "valid") at module.c:209
>>>#12 0x0000000000402f0d in mod_loadConstTable (mod=0x2aaab089cfb8, finfo=0x2aaab0989fb8) at module.c:322
>>>#13 0x0000000000403a4b in mod_loadFun (mod=0x2aaab089cfb8, name=0x2aaab098bff8 "queens", obj=0x2aaab0983ff0) at module.c:439
>>>#14 0x0000000000403cb4 in mod_loadObject (mod=0x2aaab089cfb8, offs=1580, obj=0x2aaab0983ff0) at module.c:514
>>>#15 0x0000000000402a13 in mod_resolve (module=0x2aaab0985ff8 "Main", item=0x2aaab0987ff8 "queens") at module.c:209
>>>#16 0x0000000000402f0d in mod_loadConstTable (mod=0x2aaab089cfb8, finfo=0x2aaab097bfb8) at module.c:322
>>>#17 0x0000000000403a4b in mod_loadFun (mod=0x2aaab089cfb8, name=0x2aaab097dff8 "main", obj=0x2aaab0979ff0) at module.c:439
>>>#18 0x0000000000403cb4 in mod_loadObject (mod=0x2aaab089cfb8, offs=1606, obj=0x2aaab0979ff0) at module.c:514
>>>#19 0x0000000000402a13 in mod_resolve (module=0x7fffffecab6c "Main", item=0x41f1b1 "main") at module.c:209
>>>#20 0x00000000004046ee in initGlobals (mainMod=0x7fffffecab6c "Main", mainFunc=0x7fffffec9708, _toplevel=0x7fffffec9710,
>>>    _driver=0x7fffffec9700) at main.c:120
>>>#21 0x0000000000404880 in init (mainMod=0x7fffffecab6c "Main", mainFunc=0x7fffffec9708, _toplevel=0x7fffffec9710, _driver=0x7fffffec9700)
>>>    at main.c:145
>>>#22 0x00000000004048de in main (argc=2, argv=0x7fffffec9808) at main.c:171



More information about the Yhc mailing list