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

[Michał Pałka]

Hi Tom.

Sorry for late reply. The patch fixes 0-malloc issue for the Queens
test. I will do some more testing using valgrind and efence and let you
know about the results, but I can't declare when.

Thanks,
Michal

On Thu, 2006-03-23 at 14:07 +0000, Tom Shackell wrote:
> 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
> 
>