Re: Mex Overflow Error Using Free Borland Compiler


Christopher Hulbert wrote:
> Rune Allnor wrote:
> > Christopher Hulbert wrote:
> >
> >>Rune Allnor wrote:
> >>
> >>>usenetseu3@xxxxxxxxx wrote:
> >>>
> >>>
> >>>>Hi All,
> >>>>I need help eliminating the source of the following Mex runtime error.
> >>>>Any question, suggestion, or criticism would be extremely helpful.
> >>>>
> >>>>I encounter this error when I execute a Mex file I programmed in C:
> >>>> "pow: OVERFLOW error"
> >>>>Matlab crashes unless I close all 70 or so dialog boxes that pop up
> >>>>with this error, which suggests to me that the problem is with how the
> >>>>Borland compiler handles overflow errors. Is this a correct assumption?
> >>>
> >>>
> >>>We checked this out in a different subthread. at leats at first glance,
> >>>
> >>>there was no help in tweaking the numerical exception handling
> >>>in the Borland compiler. It might not have been irrelevant, but
> >>>it was not the main cause of your problems.
> >>>
> >>>
> >>>
> >>>>The reason why I'm running into this problem is obvious to me; my Mex
> >>>>file contains unavoidably complicated equations representing the 3D
> >>>>dynamics of an object that I am simulating. On the other hand,
> >>>>"complicated equations" is no reason to give up on research, and so I'm
> >>>>looking for ways to simulate this object without having Matlab crash on
> >>>>me. I've been unsuccessful so far, and need help from a more
> >>>>experienced programmer than I.
> >>>>
> >>>>The first thing I tried is dynamic memory allocation. Other posts in
> >>>>this newsgroup suggested mxCalloc was the way to go, but this didn't
> >>>>work for me. My first question is: what's wrong with how I'm using
> >>>>mxCalloc? Relevant code snippets are at the very end of this post.
> >>>
> >>>
> >>>One criticism against your program, is that I wouldn't use mxCalloc
> >>>for internal variables, only for those that will be returned back
> >>>to the matlab workspace after the CMEX program has terminated.
> >>>Use MALLOC/CALLOC to allocate iunternal variables if you
> >>>program C, NEW if you program C++. And don't forget to delete
> >>>those variables before your program returns to matlab!
> >>
> >>Why not use mxCalloc or the like? They work just fine. That's an opinion and
> >>shouldn't be a criticism.
> >
> >
> > Maybe you are right. I prefer to keep things clean and use
> > matlab-specific
> > C code to matlab-specific tasks. Which means handling the interface
> > between matlab and the C program.
> >
> > I have browsed a few threads in th past where people have had
> > problems with memory allocation/freeing. I don't know how matlab
> > handles memory questions, so I prefer to use the C functions I know.
> >
> >
> >> I would however have 2 notes on the original code
> >>which is:
> >>1- You declare the variables of type double and allocate of size long double.
> >>2- If these are scalars, why allocate the memory? You allocate 1 of each. This
> >>would clean up a lot of code by eliminating the pointer dereferences.
> >
> >
> > Agreed.
> >
> >
> >>>Dynamic memory allocation might make it worse. "Wild pointers" are
> >>>infamous problems in C and C++, and might cause the type of problems
> >>>you see. A "wild pointer" is a pointer that does not point to where you
> >>>
> >>>think it points, so it may introduce garbage numbers into your
> >>>computations. Another type of error associated with "wild pointers"
> >>>is the "segmentation violation" error. This happens when the ponter
> >>>attempts to access memory that has not been allocated by the OS.
> >>
> >>My suggestion would be to set pointers to NULL after freeing them.
> >
> >
> > It would help the book-keeping, but it does not help with the
> > question of wild pointers.
>
> You'll get exceptions a lot quicker dereferncing a NULL pointer than a "wild
> pointer"; that was the point. What you define as "wild" i'm not quite sure. I
> would imagine it includes using memory that you have already freed (which
> setting the pointer to null would help). If you simply mean out of bounds
> indexing then that's hard to catch without compiler-implemented bounds checking.

A "wild" or "rouge" pointer is one that is supposed to point to address
a but
points somewhere else. It could be an indexing problem, in C you might
happen to try to access address p[N] in an N-point array. In C the
array
is indexed from 0 to N. This is the type of programming error that
causes a "index exeeds matrix dimension" error in matlab.

> >>>Another possible cause of these types of errors is that you have not
> >>>initialized the memory you allocate. MALLOC and CALLOC assign
> >>>a segment of memory to one variable, accessible through a pointer,
> >>>but they do not prepare the segment of memory for use. So if you
> >>>attempts to read from an allocated but not initialized variable,
> >>>you end up introducing garbage in your computations.
> >>>
> >>>So to be safe, every time you allocate some memory by MALLOC
> >>>or similar, run through the array and set all floats to 0.
> >>
> >>Although not guaranteed by the standard, many platforms have all bit 0
> >>representation for floating point 0.0 in which case mxCalloc (which the OP used)
> >>would initialize all the data to 0. Just to iterate again though, it's not
> >>guaranteed by the standard and should not be relied on.
> >
> >
> > This is the why I try to keep inside the standard. Somebody who is
> > used to a compiler that initiates memory, and relies on it to happen,
> > might be in trouble once the program is ported somewhere else.
>
> I agree you should stick to the standard when possible, the point was that
> memory initialization is probably not the culprit in this case.
>
> >
> >
> >>>>I am compiling my Mex file in Matlab 7 R14 with the free Borland C++
> >>>>compiler v5.5.1. The Matlab lcc compiler would not compile my
> >>>>equations. Has anyone encountered this error before, and have any
> >>>>suggestions on how to proceed?
> >>>
> >>>
> >>>This is and indication that there are some syntax errors or structural
> >>>errors in your code. I would suggest you make an effort to enforce some
> >>>
> >>>standard programming style to your programs. C and C++ are very
> >>>wide spread, lots of people sell compilers, and all make their own
> >>>twists and extensions to the programming language. This makes
> >>>it difficult to port programs from one system to another, some times
> >>>even between compilers on the same system.
> >>
> >>The OP should post the errors produced by lcc to determine why lcc wouldn't
> >>compile the code.
> >
> >
> > Agreed.
> >
> >
> >>Perhaps it's becuase C is case sensitive and you used Cos
> >>instead of cos and I do not know what Power is. Perhaps you meant pow in math.h?
> >>
> >>
> >>>To avoid such problems, there exists a standard for the C language,
> >>>"ANSI C", that specifies what ought to be a common mutual basis
> >>>for all C and C++ compilers. I have found that life is a lot easier
> >>>when I stay within the ANSI standard. I miss out on some of the
> >>>nifty peculiarities of this and that compiler, but when I have a
> >>>working program, it compiles and runs everywhere.
> >>>
> >>>
> >>>
> >>>>My fourth and last question: can anyone
> >>>>suggest a better (freely available) compiler for my Mex files?
> >>>
> >>>
> >>>No, lcc ought to be OK. Maybe not optimal, but more than good
> >>>enough. I think your problem has more to do with the C code
> >>>itself and not the compiler.
> >>
> >>You can try the GNU C compiler available on mingw or cygwin.
> >
> >
> > No, don't! While the GNU compiler is free and available everywhere,
> > it compiles just about any C code, good or bad. It might be a tool
> > useful
> > to an experienced C programmer, but a novice will just develop all
> > sorts
> > of bad habits that will cause trouble later.
>
> Anything can be good/bad. There is nothing worse in gcc than any other
> compiler. Every compiler offers extensions to the language. Hence the flags
> -std and -ansi. And gcc produces warning results when requested (see -W). You
> should also blame those who misteach the language for bad habits. Such as
> casting malloc or void * values. All through high-school and college I was
> taught that, however it is not necessary and can mask many errors.

Well, I used gcc in the early years, because it was available
everywhere,
free, and all that. After having spent a couple of years learning C and

implementing useful stuff, I had to spend half that time again finding
out
why my code didn't work anymore when I tried to compile it with
proprietary compilers on the new systems. There is a reason why
I stick with the ANSI standard.

If I have to use gcc now, I know that I will want to force it to accept
only
ANSI code and I know how to do it. But I did not know at the time,
which slowed me down considerably. No need to encourage others to
repeat the mistakes.

> >>>>As I said earlier, any small suggestion would probably be extremely
> >>>>helpful, especially as I'm new to both Mex and C programming.
> >>>
> >>>
> >>>I found one line in your code below, that worries me:
> >>>
> >>> *x7dotdot = (l*(4**x6dot**x7dot*M*(-1 + ...
> >>>
> >>>Maybe this is well-defined in the C language, but it might not be.
> >>>The problem is "operator precedence". You may not have heard the
> >>>term before, but you are alreday familiar with the idea from basic
> >>>maths.
> >>
> >>This is well defined in C. In ISO C99 section 6.5.5 (Multiplicative Operators)
> >>the Constraints are then both operands shall have arithmetic type. The operands
> >>of the % operator shall have integer types. therefore the compiler cannot
> >>interpret constant * * pointer as the multiplication of a pointer.
> >
> >
> > First, there are two "**" operations there. Note the x6dot**x7dot
> > statement.
> > A pointer is, by definition, an arithmetic type, or a statement like
> >
> > float *a;
> > float b;
> >
> > :
> > :
> >
> > b = *(a+n*m);
> >
> > would not be possible.
>
> Wrong, a pointer is not an arithmetic type. The reason that expression is valid
> is in section 6.5.6 of the C99 standard which says that for additive
> expressions both operands shall have arithmetic type of one operand shall be a
> pointer to an object type and the other shall have integer type. For
> subtraction the constraints add the possibility of both operands being pointers
> and hence ptrdiff_t. In your case a is a pointer and n*m is likely an integer
> although you haven't declared it.

OK, I haven't read the standard. I only have hard-won experience that
one
should never take anything for granted or assume anything, when
programming C. There used to be a proverb along the lines of "C does
exactly what it is told to do. It is the programmer's task to tell it
to do
sensible things."

> >>>In your program you have a construct like
> >>>
> >>> float *a;
> >>> float b;
> >>> float x;
> >>>
> >>> /* initializations */
> >>>
> >>> x = b**a;
> >>>
> >>>To me, as a human reader, it is obvious that you want x to contain
> >>>b times the number contained in the memory location a points to.
> >>>There is a *slight* chance that some compilers can be confused into
> >>>thinking this means "multiply the pinter a by b, and use the numebr
> >>>that is kept in the new memory location",
> >>>
> >>> x = *(b*a);
> >>
> >>This totally changes the expression. You've moved an operator to the other side
> >>of an operand.
> >
> >
> > No, I have not. I have made explicit the alternative interpretation of
> > a
> > possibly ill-defined operation on pointers.
>
> Ok, x = *(b*a) does follow from your paragraph. When I said it changed the
> expression I was referencing x = b**a. Although the former expression follows
> your textual conclusion the conclusion itself that the latter expression
> (x=b**a) can be interpreted that way is wrong.

You were right. I posted a refutation of my own arguments probaly while

you were busy writing.

Rune

.

Relevant Pages

  • Re: ARM/Linux: Is this a cross-compiler bug? ¡]memcpy doesnt work as expected)
    ... memory by casting a pointer from A to B. The compiler is ... pointers point to different memory. ... What the standard says is not relevant. ...
    (comp.arch.embedded)
  • Re: Just how delicate are freed pointers?
    ... Brutally optimising C compiler. ... I dug up an olde copy of the C Standard. ... if it's x86 architecture or not), ... perform indirection through that pointer. ...
    (comp.lang.c)
  • Re: Plz explain me the following code
    ... actually dereference a NULL pointer. ... Does a compiler that generates such code satisfy the "restrictions ... there's no need to mention them in the C standard, ...
    (comp.lang.c)
  • Re: A C++ Whishlist
    ... > Again the standard is a baseline not the end all. ... >>The 'this' pointer cannot be NULL. ... The compiler is not, however, a C++ compiler. ... Again, misrepresenting what I said. ...
    (comp.lang.cpp)
  • Re: union access
    ... The first compiler I used (not a C ... > I think Mark was asking whether there are historical reasons a ... > a pointer value to an integer object. ... arithmetic type. ...
    (comp.lang.c)
Quantcast