Strange ROMCC failure with Rev 5623

[Myles Watson]

When compiling asus/p2b (and several others), Rev 5622 succeeds, but 5623 fails.

make: *** [build/mainboard/asus/p2b/romstage.inc] Segmentation fault
make: *** Deleting file `build/mainboard/asus/p2b/romstage.inc'

The only difference for these boards is this line in config.h:

#define CONFIG_VENDOR_ECS 0

Removing this line lets 5623 build correctly.

Is there some limit on the length of this file?  The number of
#defines?  I'm using the reference compiler to compile romcc.

Thanks,
Myles

[Myles Watson]

On Wed, Jun 16, 2010 at 12:00 PM, Myles Watson  wrote:
> When compiling asus/p2b (and several others), Rev 5622 succeeds, but 5623 fails.
>
> make: *** [build/mainboard/asus/p2b/romstage.inc] Segmentation fault
> make: *** Deleting file `build/mainboard/asus/p2b/romstage.inc'
>
> The only difference for these boards is this line in config.h:
>
> #define CONFIG_VENDOR_ECS 0
>
> Removing this line lets 5623 build correctly.

Removing any line from the file that doesn't affect the build works.
(CONFIG_VENDOR_*, CONFIG_DEFAULT_CONSOLE_LEVEL_*, etc.)

Thanks,
Myles

[Myles Watson]

On Wed, Jun 16, 2010 at 12:06 PM, Myles Watson  wrote:
> On Wed, Jun 16, 2010 at 12:00 PM, Myles Watson  wrote:
> > When compiling asus/p2b (and several others), Rev 5622 succeeds, but 5623 fails.
> >
> > make: *** [build/mainboard/asus/p2b/romstage.inc] Segmentation fault
> > make: *** Deleting file `build/mainboard/asus/p2b/romstage.inc'
> >
> > The only difference for these boards is this line in config.h:
> >
> > #define CONFIG_VENDOR_ECS 0
> >
> > Removing this line lets 5623 build correctly.
>
> Removing any line from the file that doesn't affect the build works.
> (CONFIG_VENDOR_*, CONFIG_DEFAULT_CONSOLE_LEVEL_*, etc.)

Program received signal SIGSEGV, Segmentation fault.
0x0000000000423bbe in free_basic_block (state=0x7fff5dbcbb20, block=0x1392ff0)
    at /home/myles/try/buildrom-devel/work/coreboot/svn/util/romcc/romcc.c:15165
15165			if (child && (child->vertex != -1)) {
(gdb) print child
$1 = (struct block *) 0x1c95950
(gdb) print child->vertex
Cannot access memory at address 0x1c959b8

Thanks,
Myles

[Myles Watson]

On Wed, Jun 16, 2010 at 4:34 PM, Myles Watson  wrote:
> On Wed, Jun 16, 2010 at 12:06 PM, Myles Watson  wrote:
> > On Wed, Jun 16, 2010 at 12:00 PM, Myles Watson  wrote:
> > > When compiling asus/p2b (and several others), Rev 5622 succeeds, but 5623 fails.
> > >
> > > make: *** [build/mainboard/asus/p2b/romstage.inc] Segmentation fault
> > > make: *** Deleting file `build/mainboard/asus/p2b/romstage.inc'
> > >
> > > The only difference for these boards is this line in config.h:
> > >
> > > #define CONFIG_VENDOR_ECS 0
> > >
> > > Removing this line lets 5623 build correctly.
> >
> > Removing any line from the file that doesn't affect the build works.
> > (CONFIG_VENDOR_*, CONFIG_DEFAULT_CONSOLE_LEVEL_*, etc.)
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000423bbe in free_basic_block (state=0x7fff5dbcbb20, block=0x1392ff0)
>    at /home/myles/try/buildrom-devel/work/coreboot/svn/util/romcc/romcc.c:15165
> 15165                   if (child && (child->vertex != -1)) {
> (gdb) print child
> $1 = (struct block *) 0x1c95950
> (gdb) print child->vertex
> Cannot access memory at address 0x1c959b8

It looks like Patrick found this before:
http://www.coreboot.org/pipermail/coreboot/2009-November/054387.html

If I take out the free it works fine.  It seems like there must be a better fix.

Thanks,
Myles

Myles Watson  writes:
> On Wed, Jun 16, 2010 at 4:34 PM, Myles Watson  wrote:
> > On Wed, Jun 16, 2010 at 12:06 PM, Myles Watson  wrote:
> > > On Wed, Jun 16, 2010 at 12:00 PM, Myles Watson  wrote:
> > > > When compiling asus/p2b (and several others), Rev 5622 succeeds, but 5623 fails.
> > > >
> > > > make: *** [build/mainboard/asus/p2b/romstage.inc] Segmentation fault
> > > > make: *** Deleting file `build/mainboard/asus/p2b/romstage.inc'
> > > >
> > > > The only difference for these boards is this line in config.h:
> > > >
> > > > #define CONFIG_VENDOR_ECS 0
> > > >
> > > > Removing this line lets 5623 build correctly.
> > >
> > > Removing any line from the file that doesn't affect the build works.
> > > (CONFIG_VENDOR_*, CONFIG_DEFAULT_CONSOLE_LEVEL_*, etc.)
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x0000000000423bbe in free_basic_block (state=0x7fff5dbcbb20, block=0x1392ff0)
> >    at /home/myles/try/buildrom-devel/work/coreboot/svn/util/romcc/romcc.c:15165
> > 15165                   if (child && (child->vertex != -1)) {
> > (gdb) print child
> > $1 = (struct block *) 0x1c95950
> > (gdb) print child->vertex
> > Cannot access memory at address 0x1c959b8
>
> It looks like Patrick found this before:
> http://www.coreboot.org/pipermail/coreboot/2009-November/054387.html
>
> If I take out the free it works fine.  It seems like there must be a better fix.

Agreed.

I took a look at this a little bit with Stefan and he helped me track where
the double free is.

The routine doing the freeing badly needs to be rewritten to use simpler logic
as the recursive logic it is using now just doesn't work, and it winds
up to be a bit of a crap shoot if your compile gets killed by this or not.

Eric

[Myles Watson]

> > It looks like Patrick found this before:
> > http://www.coreboot.org/pipermail/coreboot/2009-November/054387.html
> >
> > If I take out the free it works fine.  It seems like there must be a better fix.
>
> Agreed.
>
> I took a look at this a little bit with Stefan and he helped me track where
> the double free is.
>
> The routine doing the freeing badly needs to be rewritten to use simpler logic
> as the recursive logic it is using now just doesn't work, and it winds
> up to be a bit of a crap shoot if your compile gets killed by this or not.

What if we just agree that host machines have a lot of RAM, romcc is
not a long-running program, and life will be easier if nothing gets
freed.  How much RAM are we talking about?  It might be easier to
debug if nothing gets zeroed.

Thanks,
Myles

[ron minnich]

On Thu, Jun 17, 2010 at 8:12 AM, Myles Watson  wrote:
> What if we just agree that host machines have a lot of RAM, romcc is
> not a long-running program, and life will be easier if nothing gets
> freed.  How much RAM are we talking about?  It might be easier to
> debug if nothing gets zeroed.

Reasonable. You could at least try it. Use LD_PRELOAD and make free()
a no-op :-)

It's ugly but sometimes ...

there are times when it's simpler to consume resources and keep in
mind that on exit, they're freed (you'd be surprised how often I have
to point out to people that doing lots of work to free memory before
calling exit() has no effect on the system free memory -- "You mean
the system can somehow free the process memory when the process
exits?" -- I'm not kidding!)

ron

[Stefan Reinauer]

On 6/17/10 5:12 PM, Myles Watson wrote:
> > > It looks like Patrick found this before:
> > > http://www.coreboot.org/pipermail/coreboot/2009-November/054387.html
> > >
> > > If I take out the free it works fine.  It seems like there must be a better fix.
> >
> > Agreed.
> >
> > I took a look at this a little bit with Stefan and he helped me track where
> > the double free is.
> >
> > The routine doing the freeing badly needs to be rewritten to use simpler logic
> > as the recursive logic it is using now just doesn't work, and it winds
> > up to be a bit of a crap shoot if your compile gets killed by this or not.
>
> What if we just agree that host machines have a lot of RAM, romcc is
> not a long-running program, and life will be easier if nothing gets
> freed.

Then we should also switch to Visual C++ in order to stay compliant. ;-)

Stefan

[Myles Watson]

On Thu, Jun 17, 2010 at 10:15 AM, Stefan Reinauer  wrote:
> On 6/17/10 5:12 PM, Myles Watson wrote:
> > > > It looks like Patrick found this before:
> > > > http://www.coreboot.org/pipermail/coreboot/2009-November/054387.html
> > > >
> > > > If I take out the free it works fine.  It seems like there must be a better fix.
> > >
> > > Agreed.
> > >
> > > I took a look at this a little bit with Stefan and he helped me track where
> > > the double free is.
> > >
> > > The routine doing the freeing badly needs to be rewritten to use simpler logic
> > > as the recursive logic it is using now just doesn't work, and it winds
> > > up to be a bit of a crap shoot if your compile gets killed by this or not.
> >
> > What if we just agree that host machines have a lot of RAM, romcc is
> > not a long-running program, and life will be easier if nothing gets
> > freed.
>
> Then we should also switch to Visual C++ in order to stay compliant. ;-)

Point taken :)

Myles

[Peter Stuge]

ron minnich wrote:
> > What if we just agree that host machines have a lot of RAM, romcc is
> > not a long-running program, and life will be easier if nothing gets
> > freed.
> > How much RAM are we talking about?
>
> Reasonable. You could at least try it. Use LD_PRELOAD and make free()
> a no-op :-)

Yes, I would be interested in how much RAM is being used.
> (you'd be surprised how often I have to point out to people that
> doing lots of work to free memory before calling exit() has no
> effect on the system free memory -- "You mean the system can
> somehow free the process memory when the process exits?" -- I'm
> not kidding!)

It's lovely. I worked on a project where the application implemented
it's own memory allocator. When starting, the program would allocate
*all* available memory in the system, and then split that up into
small parts as the program progressed. The boss was convinced that
the operating system could not be trusted to do memory management.
They're still in business, I expect still running the same code.

Stefan Reinauer wrote:
> > What if we just agree that host machines have a lot of RAM, romcc is
> > not a long-running program, and life will be easier if nothing gets
> > freed.
>
> Then we should also switch to Visual C++ in order to stay compliant. ;-)

He-he.. But depending on the resource use I would be okey with making
an exception for romcc.

//Peter

[Anders Jenbo]

tor, 17 06 2010 kl. 22:14 +0200, skrev Peter Stuge:
> ron minnich wrote:
> > > What if we just agree that host machines have a lot of RAM, romcc is
> > > not a long-running program, and life will be easier if nothing gets
> > > freed.
> > > How much RAM are we talking about?
> >
> > Reasonable. You could at least try it. Use LD_PRELOAD and make free()
> > a no-op :-)
>
> Yes, I would be interested in how much RAM is being used.
> > (you'd be surprised how often I have to point out to people that
> > doing lots of work to free memory before calling exit() has no
> > effect on the system free memory -- "You mean the system can
> > somehow free the process memory when the process exits?" -- I'm
> > not kidding!)
>
> It's lovely. I worked on a project where the application implemented
> it's own memory allocator. When starting, the program would allocate
> *all* available memory in the system, and then split that up into
> small parts as the program progressed. The boss was convinced that
> the operating system could not be trusted to do memory management.
> They're still in business, I expect still running the same code.

They should make there software in to payloads for coreboot ;D
> Stefan Reinauer wrote:
> > > What if we just agree that host machines have a lot of RAM, romcc is
> > > not a long-running program, and life will be easier if nothing gets
> > > freed.
> >
> > Then we should also switch to Visual C++ in order to stay compliant. ;-)
>
> He-he.. But depending on the resource use I would be okey with making
> an exception for romcc.
>
> //Peter