• State Not Answered
  • Locked Locked
  • Replies 11 replies
  • Subscribers 22 subscribers
  • Views 1701 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

C51 v7.20 WinXP Exception

Drew Davis

We have a new machine running a new version of the compiler that's having a problem. It's Cx51 v7.20, run from uVision, on top of WinXp Media Center Edition (hey, it was there), plus Cygwin.

When the compiler runs, a couple of "send problem report to Microsoft" exception dialogs pop up when compilation reaches a particular couple of files. It's always the same two files, which may be just a matter of when they're reached in the compilation process, or perhaps something about the files themselves.

There's nothing wrong with the project or these particular files. We have two other machines (running XP Pro pre- and post-SP2 and C51 v7.05 / v7.09) that work fine on exactly the same input (project files and source).

Sound familiar to anyone? Any suggestions on what might be going wrong?

Parents Reply Children
  • 0 in reply to Andy Neil

    So rumours of your death have been greatly exaggerated:


    It's Strange how rumors about ones death get started.

    Elvis Presley
    Elvis.Presley@graceland.net

  • 0 in reply to Elvis Presley

    I emailed Brian a new file earlier today. So, for those of you that like to play along at home:

    #include <stdlib.h>
#include <stdio.h>

#define	MY_BASE				0xf000
#define MyAddress(offset)	(MY_BASE + (offset << 3))
#define PortTable(offset)	((volatile unsigned int *) MyAddress(offset))
#define PortVal				PortTable(0xbcd)

void cmd (int argc, const char * const argv[])
{
	unsigned int ui;

	if (argc > 3)
	{
		ui = strtoul (argv[3], NULL, 0);

		ui = PortVal + 1;
//		ui = ((volatile unsigned int *) (0xf000 + (0xbcd << 3)));
	}
}

void main (void)
	{
	cmd (2, NULL);
	for (;;);
	}

    There. More like a real program now, though of course still pointless.

    The point, of course, is to have a minimalist example that produces the problem (whether it does anything useful or not). This code is a stripped and santized version of the real thing, a eidolon of its original form devoid of real meaning and purpose in life.

    The "PortVal + 1" line causes the 7.20 compiler to access memory out of bounds (Windows exception 0xc0000005). The commented line, where the macros have been expanded by hand, does not cause a crash. This makes me suspect the preprocessor. 7.05 will compile either version.

    I didn't try to get the example to link. Among other things, it's missing an L51_BANK and bank switching is enabled in the project file.

    My coworker (who actually is the one experiencing the problem) mentioned that removing the #include's will cause the compiler to successfully complete, but I haven't tried that myself.

  • 0 in reply to Elvis Presley

    I emailed Brian a new file earlier today. So, for those of you that like to play along at home:

    #include <stdlib.h>
#include <stdio.h>

#define	MY_BASE				0xf000
#define MyAddress(offset)	(MY_BASE + (offset << 3))
#define PortTable(offset)	((volatile unsigned int *) MyAddress(offset))
#define PortVal				PortTable(0xbcd)

void cmd (int argc, const char * const argv[])
{
	unsigned int ui;

	if (argc > 3)
	{
		ui = strtoul (argv[3], NULL, 0);

		ui = PortVal + 1;
//		ui = ((volatile unsigned int *) (0xf000 + (0xbcd << 3)));
	}
}

void main (void)
	{
	cmd (2, NULL);
	for (;;);
	}

    There. More like a real program now, though of course still pointless.

    The point, of course, is to have a minimalist example that produces the problem (whether it does anything useful or not). This code is a stripped and santized version of the real thing, a eidolon of its original form devoid of real meaning and purpose in life.

    The "PortVal + 1" line causes the 7.20 compiler to access memory out of bounds (Windows exception 0xc0000005). The commented line, where the macros have been expanded by hand, does not cause a crash. This makes me suspect the preprocessor. 7.05 will compile either version.

    I didn't try to get the example to link. Among other things, it's missing an L51_BANK and bank switching is enabled in the project file.

    My coworker (who actually is the one experiencing the problem) mentioned that removing the #include's will cause the compiler to successfully complete, but I haven't tried that myself.

  • 0 in reply to Drew Davis

    It fails on my system here as well. I forwarded your example to engineering.

    Jon

  • 0 in reply to Drew Davis

    "This makes me suspect the preprocessor"

    Do you mean you suspect that the preprocessor is crashing, or you suspect that the preprocessor is generating something that makes the compiler crash?

    If the latter, have you tried looking at the preprocessor listing?

  • 0 in reply to Andy Neil

    Checking the preprocessor listing box gave me some odd results. The first time I tried it, the compiler ran successfully. Turn the .i off, crash. On, runs. Off, crash.

    I played with that briefly, restarted uVision, and now the compiler crashes either way.

    But to answer the question, the behavior made me suspicious of the processor itself, perhaps some sort of buffer overflow while recursively expanding those four #define's.