First to clear something up : my toolchain build problem is solved, you may have missed that in the many messages on the list these days. Apparently some of the newlib files get compiled wrong with the default build options (-O2 -O).
On Sat, 2007-04-21 at 04:11 +0200, Jan Rinze wrote:
> > 2. Pedro asked why I used a dialog, wouldn't a printf statement be
> > better, he mentioned console applications.
> > I've tried to build a "console" version of my follow-a-null-pointer
> > application using the old voxware compiler. I used that toolchain
> > because I don't think ours can handle a console application that
> > can be launched from the rlogin session.
>
> hmm.. that would be an issue by itself. I have run different tests in a
> console on various things with cegcc but always used telnet for that.
> don know about rlogin on the pocket pc.
Out of curiosity - which telnet server do you use?
> > The console application died as expected, showing messages that appear
> > to come from the _eh_handler_ :
> >
> > # np.exe
> > Exception: Code:c0000005 Flags:0 Addr:11060 SP:2009fb44 LR:11054 R0:0
> > R1:29150 R2:2 R3:0 R4:2009fb64 R5:2009fc7c R12:1 FP:2009fb4c
> > Exception: Code:c0000005 Flags:0 Addr:11060 SP:2009fb44 LR:16194
> > R0:ffffffff R1:0 R2:24be49ba R3:0 R4:c0000005 R5:0 R12:1 FP:2009fb4c
> > Exception: Code:80000002 Flags:0 Addr:16198 SP:2009fb44 LR:16194
> > R0:ffffffff R1:0 R2:24be49ba R3:86 R4:c0000005 R5:ffffffff R12:1
> > FP:2009fb4c
> > #
>
> why 3 exceptions? should not one be enough and stop the program ( or am
> I missing the correct mindset here to understand what is going on?)
Haven't looked into this one yet.
> > Interestingly, the divide-by-zero application (which pops up a dialog
> > after the division by 0) shows a dialog on my PDA's screen, even
> > though it was launched as a console application (from the rlogin
> > session).
> >
>
> could be from the floatingpoint emulator (if that exists on wince)
Again I should have been more clear. The app is
#include <stdio.h>
#include <stdlib.h>
main()
{
double a, b;
b = 0.0;
a = 1.0 / b;
MessageBoxW(0, L"All done", L"main", 0);
return;
}
and it doesn't crash on the division, it does show the "All done" dialog
even when it was run from an rlogin session. The point is that the
dialog shows up at all.
> > 4. I have an application that mysteriously dies when you ask it too
> > much. I was hoping to get some info from this handler, but I have yet
> > to find any error message.
> >
>
> Danny, the above statement is wonderfull.. You should never ask too much
> of an application ;-) Most people react in the same way if you ask too
> much of them :-)
>
> Just out of curiosity, what kind of app are you talking about and could
> you be more specific to the situation when it crashes? Stack overflow or
> something like that? (the memory model of wince is pretty restrictive
> i.m.h.o.)
Once more, I tried to express too much with a limited amount of
words :-)
It is an application I built myself, a port of Xinvest
(http://xinvest.sunsite.dk) which I call PocketInvest. The sources are
in the same CVS as Xinvest, they overlap quite a bit.
There's a report window, in which you can ask for analysis of your stock
evolution over several periods. It is possible to have several periods
(a month, last quarter, a year, ..) selected at the same time, the
report gets bigger (more information is created).
With one or two report periods, the app works. When I select five ("too
much"), the application mysteriously dies.
I have no idea why, the only thing I know is what gdb say (see below)
but I can't map the address into a known location in the source.
This mysterious crash is one of the reasons why I started looking into
exception trapping.
Any clues ?
Danny
> > When I run it under gdb, all that happens is :
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x01758f58 in ?? ()
> > (gdb) where
> > #0 0x01758f58 in ?? ()
> > (gdb)
> >
>
> sounds like a trashed stack. This can happen when you define arrays
> within a function (created on the stack) and write outside the array
> bounds.
>
> > Danny
>
> I hope you get your cegcc stuff back in order.
> The stack trashing is very hard to avoid in gcc, programmers should just
> be more carefull when writing to certain memory locations. it looks like
> you are stumbling over some badly written pieces of code.
>
> Jan Rinze.
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
_______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
