xalloc win/unix

[CMeyers99]

Hi,

first of all I have to admit, that I'm not a c-programmer.
Usually I'm programming java. But now I have to include some c source code in my Java application by using java native interface. Im using the Microsoft c-compiler that comes with MS VisulalC++ 5.0.

I encountered a weird problem:
I recieve an "Application Error":
"The exception Breakpoint
A breakpoint has been reached
[0x80000003] occured in the application at location 0x02c9d330"
But there is no breakpoint anywhere in my code!
I can then choose to debug the program, which brings my to a file dbgheap.c.
The header says:
/***
*dbgheap.c - Debug CRT Heap Functions
*
* Copyright (c) 1988-1997, Microsoft Corporation. All rights reserved.
*
*Purpose:
* Defines debug versions of heap functions.
*
********************************************************/

The line that produces the error is:
/* break into debugger at specific memory allocation */
if (lRequest == _crtBreakAlloc)
_CrtDbgBreak();

The corresponding line in my c code is:

po = (Parse_Options) xalloc(sizeof(struct Parse_Options_s));

The c code I'm using is actually written for Unix/Linux plattforms, and I wonder if that might be the source for the error.

The Mircosoft helps tells me xalloc does the following:
"Microsoft C++ implements an alternate method of handling new memory allocation failure, based on the current ANSI C++ working paper proposal. Using this method, a new run-time function, _standard_new_handler, throws a C++ exception of type xalloc in the event of a new allocation failure. xalloc exceptions are based on an exception class hierarchy, defined in EH.H."

On the other hand, standard c++ defines xalloc like that:
"Return a new index for the internal extensible array.
Provides a new index to be used with member functions in the internal extensible array.
This is a static member function. "

To me that seems to be something different.
As I said, I'm a java programmer actaully, so I'm a bit lost ATM.
Does somebody know what's going on here?
Can I change that line of code somehow, so that it uses something else than xalloc?

Any help is highly appreciated!

Thanks a lot,
Carl

 

[Salem]

> Can I change that line of code somehow, so that it uses something else than xalloc?
Well its a pretty safe bet that if this code came from Linux, and is written in C, then the xalloc() does not mean what VC++ takes it to mean.
A quick way to restore the ANSI-C meaning would be to add this line after all the #include lines

#define xalloc malloc

The other problem may be that the code is actually buggy (seems likely). Porting code from one OS/Compiler to another is a good way of flushing out previously undetected bugs. Unfortunately, malloc related bugs are some of the hardest to find, because cause (where the problem really is) and effect (where your program crashes inside some malloc routine) are seldom one and the same.


--

 

[dangav]

Hi,

I've encountered an error on the same line, and have found the cause but no MS-supported fix. I'll reiterate here what I found in case its of use to you... First of all, does your code do a high number of memory allocations?

Basically in debug builds "lRequest" is the number of memory allocation requests that have occured via these routines. _crtBreakAlloc is actually a kind of virtual breakpoint that you can set in your code to trip this if statement. The code below as it stands does not handle extremely high numbers of allocations (2 billion or so? I forget the range for a long in MSVC).

/* break into debugger at specific memory allocation */
if (lRequest == _crtBreakAlloc)
_CrtDbgBreak();

The problem is that when the counter wraps, this code is erroneously tripped as _crtBreakAlloc's default value is '-1'. This is fine if you do less than 2 billion allocation requests, it'll never trip ... I know for a fact that my code is more than likely going beyond this ... is yours?

To fix it you need to code something like the following into the above (note this is copied from another forum, not yet tested by me).

if ((lRequest == _crtBreakAlloc) && (_crtBreakAlloc != -1))
_CrtDbgBreak();


Hope this helps!

 

[chipperMDW]

On Linux and other GNU systems, [tt]xmalloc[/tt] is a conventional way to avoid checking the return value from [tt]malloc[/tt]. If [tt]malloc[/tt] fails to allocate memory you usually just want to quit the program. [tt]xmalloc[/t] calls [tt]malloc[/tt] checks the return value, then exits if [tt]malloc[/tt] failed. Thus, if [tt]xalloc[/tt] returns, the memory is always valid.

Saying

#define xalloc malloc

would probably work (unless it angered something in a Windows header), but it would also make the program breakable; [tt]malloc[/tt] can return a NULL pointer, but code using [tt]xmalloc[/tt] expects the memory to be valid.

Thus, you probably need to rename the [tt]xmalloc[/tt] routine to something else. If I remember correctly, [tt]xmalloc[/tt] is actually a keyword in Visual C++, so that's probably your best option.

 

[dangav]

PS - In answer to your comment "But there is no breakpoint anywhere in my code!"

Have a look at the article in MSDN titled

"Using Macros for Verification and Reporting"

_CrtDbgBreak() is an MS routine and acts as an in-code breakpoint. Its used by the _ASSERT and _ASSERTE macros to break when assertions fail.

HTH
D