Home > Archive > Clipper > November 2004 > Weird GPF Crash
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Mel Smith 2004-11-19, 3:55 pm |
| Dear Friends,
Enviro: a protected mode app (with Packcode, Packdata, and Compress in the
..lnk file) using Clipper 5.2e and Blinker 5.1
After an hour of testing/fixing I have resolved a weird GPF.
I was making extensive changes in a tbrowse module (shopbrow.prg), and after
quite a few changes, compiled the app (approx 76 modules).
The compile was successful.
When I started up the app, I got an immediate GPF !! (I didn't even get into
the main menu !)
After a bunch of work (i.e., checking the new code against a back up copy,
and gradually building the new module again, I finally got to an innocuous
assignment statement that cause the crash:
dSAVCHKDTE := CHEKDATE // dSAVCHKDTE is a private vrbl
Removing this statement resolved the GPF but caused me terrible confusion.
After much more work I made the dSAVCHKDTE a LOCAL vrbl and this removed the
GPF.
Can anybody explain this GPF cause & cure to me ???
BTW, I went over the whole module again, and 'LOCALized' all the vrbls that
I possibly could, and I'm back-in-action again after a 'terrifying' morning (I
'terrify' easily these days :)) )
TIA,
-Mel Smith
| |
| Ron Pinkas 2004-11-19, 3:55 pm |
| Mel
> Can anybody explain this GPF cause & cure to me ???
Clipper is prone to have such "mysterious" issues, once you reach certain
application size, or memory utilization. I'd strongly urge you to recompile
your application with xHarbour (http://www.xHarbour.org), to rid yourself
from all such restrictions.
Ron
| |
| Mel Smith 2004-11-19, 8:55 pm |
| Ron,
Thanks !
Moving to xHarbour is at the top on my list, and I have started moving this
app tentatively to xHarbour over the past two months -- but I still like
Clipper as my 'warm blanket' :))
Also, my customer is still hitting me with new changes required nearly daily
in this and four other apps (and I get paid to satisfy these needs first).
Thanks again,
-Mel Smith
| |
| Ron Pinkas 2004-11-20, 3:55 am |
| Mel,
> Moving to xHarbour is at the top on my list, and I have started moving
> this
> app tentatively to xHarbour over the past two months -- but I still like
> Clipper as my 'warm blanket' :))
Recompiling Clipper console application with xHarbour should be fairly
transparent process. The most obvious issue is having to address misspelled
Symbols (when longer than 10 characters). Please feel welcome to report any
difficulty you encounter.
Ron
| |
|
| Ron,
Have been thinking of moving to xHarbour for some time but have a couple of
concerns that I can't find answers to on your website or in the Clipper NG.
(Maybe I'm looking in the wrong place!)
- the application I need to port uses a number of external libs e.g.
Silverclip, Funcky and Clipper Tools. Will I still be able to call these
functions or will I need new libs with similar functionality to compile and
link with xHarbour?
- I have a small amount of C code that has been compiled to an .obj with the
Microsoft V5.1 ( I think ) compiler. Will I still be able to link it with
Llibce.lib, or will it have to be rewritten?
Thanks for the help.
--
Rob Grattan
R&D Software Pty. Ltd.
| |
| Ron Pinkas 2004-11-20, 3:55 pm |
| Rob
> Have been thinking of moving to xHarbour for some time but have a couple
> of concerns that I can't find answers to on your website or in the Clipper
> NG. (Maybe I'm looking in the wrong place!)
> - the application I need to port uses a number of external libs e.g.
> Silverclip, Funcky and Clipper Tools. Will I still be able to call these
> functions or will I need new libs with similar functionality to compile
> and link with xHarbour?
I'm not familiar with SilverClip, Funcky is available as OLE Server, and
most functions of Clipper Tools are available.
> - I have a small amount of C code that has been compiled to an .obj with
> the Microsoft V5.1 ( I think ) compiler. Will I still be able to link it
> with Llibce.lib, or will it have to be rewritten?
C code for Clipper in most cases needs just to be recompiled, with minor
S&R modification.
Ron
| |
|
| Ron,
Thanks for the prompt reply. As usual, answers prompt more questions...:
- Silverclip is a Comms library for accessing the Serial Port/modems. I
think there are comms functions in Clipper Tools so I should be ok?
- Not sure what you mean by recompiling the C code - recompiling with what -
a later version of the Microsoft C compiler?
- Sorry - S&R? Syntax and ?? Could you elucidate?
--
Rob Grattan
R&D Software Pty. Ltd.
| |
| Ron Pinkas 2004-11-21, 3:55 am |
| Rob,
> - Silverclip is a Comms library for accessing the Serial Port/modems. I
> think there are comms functions in Clipper Tools so I should be ok?
The commercial version of xHarbour from http://www.xHarbour.com includes
CT3Comm.lib which offeres all the functionality of the CT3 comm functions.
> - Not sure what you mean by recompiling the C code - recompiling with
> what - a later version of the Microsoft C compiler?
If using the commercial version of xHarbour then with it's included C
compler (xCC), otherwise with your C compiler of choice.
> - Sorry - S&R? Syntax and ?? Could you elucidate?
Sorry, "Search & Replace".
Ron
| |
|
| Ron,
Thanks for that. I'm going to be travelling for a couple of w s but it
looks like I'll have to have a 'play' with the xHarbour I downloaded some
time ago when I get back. Thanks for the help...
--
Rob Grattan
R&D Software Pty. Ltd.
| |
| tom knauf 2004-11-22, 8:55 pm |
| Hi there,
just to complete :
Beware of .obj Files > 64 KB : split .prg into multiple parts
Beware of too many .obj files : merge .prg together (yes I know the last
line , life sometimes is not easy)
as you did : change private to locals
Update to blinker 7, this cured many mysterious errors and the mouse crash
on 5.3 under xp
and if anything fails : just include some statements like nDummy := 0,
cDummy := "zuzuzu"
it sounds like voodoo, but it helps
Greetings
tom
"Mel Smith" <medsyntel@aol.comnocrud> schrieb im Newsbeitrag
news:20041119132743.06280.00000527@mb-m26.aol.com...
> Dear Friends,
>
> Enviro: a protected mode app (with Packcode, Packdata, and Compress in
the
> .lnk file) using Clipper 5.2e and Blinker 5.1
>
> After an hour of testing/fixing I have resolved a weird GPF.
>
> I was making extensive changes in a tbrowse module (shopbrow.prg), and
after
> quite a few changes, compiled the app (approx 76 modules).
>
> The compile was successful.
>
> When I started up the app, I got an immediate GPF !! (I didn't even get
into
> the main menu !)
>
> After a bunch of work (i.e., checking the new code against a back up
copy,
> and gradually building the new module again, I finally got to an innocuous
> assignment statement that cause the crash:
>
> dSAVCHKDTE := CHEKDATE // dSAVCHKDTE is a private vrbl
>
> Removing this statement resolved the GPF but caused me terrible
confusion.
>
> After much more work I made the dSAVCHKDTE a LOCAL vrbl and this
removed the
> GPF.
>
> Can anybody explain this GPF cause & cure to me ???
>
> BTW, I went over the whole module again, and 'LOCALized' all the vrbls
that
> I possibly could, and I'm back-in-action again after a 'terrifying'
morning (I
> 'terrify' easily these days :)) )
>
> TIA,
>
> -Mel Smith
>
>
>
| |
| Mel Smith 2004-11-23, 3:55 am |
| Ron,
Thanks !
Moving to xHarbour is at the top on my list, and I have started moving this
app tentatively to xHarbour over the past two months -- but I still like
Clipper as my 'warm blanket' :))
Also, my customer is still hitting me with new changes required nearly daily
in this and four other apps (and I get paid to satisfy these needs first).
Thanks again,
-Mel Smith
| |
| Klas Engwall 2004-11-23, 3:55 am |
| Tom,
>Beware of .obj Files > 64 KB : split .prg into multiple parts
According to David Lyon at CA it is not the .OBJ file size itself but
the size of the symbol table (reported at the end of the compilation)
that must not exceed 64 KB. Although your suggestion can be used as an
approximate rule of thumb it is in reality unnecessarily restrictive.
This is what David said on the Clipper forum on Compuserve a long time
ago:
"CA-Clipper is able to properly access a symbol table of up to 64
KBytes at runtime. Impirically keeping compiled target .OBJ file size
below 64 KBytes makes it impossible to accidentally exceed this
benchmark limitation. (An .OBJ can obviously sometimes be quite a lot
larger than 64 KBytes without exceeding this symbol table size
benchmark limitation.)"
Regards,
Klas
-------
klas dot engwall at engwall dot com
Spammers, please use this address :-) mailto:postmaster@[127.0.0.1]
| |
|
| Ron,
Have been thinking of moving to xHarbour for some time but have a couple of
concerns that I can't find answers to on your website or in the Clipper NG.
(Maybe I'm looking in the wrong place!)
- the application I need to port uses a number of external libs e.g.
Silverclip, Funcky and Clipper Tools. Will I still be able to call these
functions or will I need new libs with similar functionality to compile and
link with xHarbour?
- I have a small amount of C code that has been compiled to an .obj with the
Microsoft V5.1 ( I think ) compiler. Will I still be able to link it with
Llibce.lib, or will it have to be rewritten?
Thanks for the help.
--
Rob Grattan
R&D Software Pty. Ltd.
| |
| Al Acker 2004-11-23, 3:55 am |
| Klas,
This goes way back to when I wrote my book on Memory Management in Clipper.
I talk about ways to keep the symbol table low. Think David must have read
my book <g>.
Al
--
Al Acker, President
Acker Consulting, Inc.
mailto:al@thexbasefiles.com
http://www.ackerconsulting.com
"Klas Engwall" <klas.engwall@nospam.please> wrote in message
news:41a29ac4.369097524@nntpserver.swip.net...
> Tom,
>
>
> According to David Lyon at CA it is not the .OBJ file size itself but
> the size of the symbol table (reported at the end of the compilation)
> that must not exceed 64 KB. Although your suggestion can be used as an
> approximate rule of thumb it is in reality unnecessarily restrictive.
>
> This is what David said on the Clipper forum on Compuserve a long time
> ago:
>
> "CA-Clipper is able to properly access a symbol table of up to 64
> KBytes at runtime. Impirically keeping compiled target .OBJ file size
> below 64 KBytes makes it impossible to accidentally exceed this
> benchmark limitation. (An .OBJ can obviously sometimes be quite a lot
> larger than 64 KBytes without exceeding this symbol table size
> benchmark limitation.)"
>
> Regards,
> Klas
>
> -------
> klas dot engwall at engwall dot com
>
> Spammers, please use this address :-) mailto:postmaster@[127.0.0.1]
| |
| Ron Pinkas 2004-11-23, 3:55 am |
| Rob
> Have been thinking of moving to xHarbour for some time but have a couple
> of concerns that I can't find answers to on your website or in the Clipper
> NG. (Maybe I'm looking in the wrong place!)
> - the application I need to port uses a number of external libs e.g.
> Silverclip, Funcky and Clipper Tools. Will I still be able to call these
> functions or will I need new libs with similar functionality to compile
> and link with xHarbour?
I'm not familiar with SilverClip, Funcky is available as OLE Server, and
most functions of Clipper Tools are available.
> - I have a small amount of C code that has been compiled to an .obj with
> the Microsoft V5.1 ( I think ) compiler. Will I still be able to link it
> with Llibce.lib, or will it have to be rewritten?
C code for Clipper in most cases needs just to be recompiled, with minor
S&R modification.
Ron
| |
|
| Ron,
Thanks for that. I'm going to be travelling for a couple of ws but it
looks like I'll have to have a 'play' with the xHarbour I downloaded some
time ago when I get back. Thanks for the help...
--
Rob Grattan
R&D Software Pty. Ltd.
| |
| Klas Engwall 2004-11-23, 8:55 pm |
| Al,
>This goes way back to when I wrote my book on Memory Management in Clipper.
>I talk about ways to keep the symbol table low. Think David must have read
>my book <g>.
Yeah, who knows? Provided he could find that particular piece of info
in it, of course. Books without indexes, bah! <BG>
Klas
-------
klas dot engwall at engwall dot com
Spammers, please use this address :-) mailto:postmaster@[127.0.0.1]
| |
| Ron Pinkas 2004-11-26, 3:55 am |
| Rob,
> - Silverclip is a Comms library for accessing the Serial Port/modems. I
> think there are comms functions in Clipper Tools so I should be ok?
The commercial version of xHarbour from http://www.xHarbour.com includes
CT3Comm.lib which offeres all the functionality of the CT3 comm functions.
> - Not sure what you mean by recompiling the C code - recompiling with
> what - a later version of the Microsoft C compiler?
If using the commercial version of xHarbour then with it's included C
compler (xCC), otherwise with your C compiler of choice.
> - Sorry - S&R? Syntax and ?? Could you elucidate?
Sorry, "Search & Replace".
Ron
| |
| tom knauf 2004-11-26, 8:55 am |
| Hi there,
just to complete :
Beware of .obj Files > 64 KB : split .prg into multiple parts
Beware of too many .obj files : merge .prg together (yes I know the last
line , life sometimes is not easy)
as you did : change private to locals
Update to blinker 7, this cured many mysterious errors and the mouse crash
on 5.3 under xp
and if anything fails : just include some statements like nDummy := 0,
cDummy := "zuzuzu"
it sounds like voodoo, but it helps
Greetings
tom
"Mel Smith" <medsyntel@aol.comnocrud> schrieb im Newsbeitrag
news:20041119132743.06280.00000527@mb-m26.aol.com...
> Dear Friends,
>
> Enviro: a protected mode app (with Packcode, Packdata, and Compress in
the
> .lnk file) using Clipper 5.2e and Blinker 5.1
>
> After an hour of testing/fixing I have resolved a weird GPF.
>
> I was making extensive changes in a tbrowse module (shopbrow.prg), and
after
> quite a few changes, compiled the app (approx 76 modules).
>
> The compile was successful.
>
> When I started up the app, I got an immediate GPF !! (I didn't even get
into
> the main menu !)
>
> After a bunch of work (i.e., checking the new code against a back up
copy,
> and gradually building the new module again, I finally got to an innocuous
> assignment statement that cause the crash:
>
> dSAVCHKDTE := CHEKDATE // dSAVCHKDTE is a private vrbl
>
> Removing this statement resolved the GPF but caused me terrible
confusion.
>
> After much more work I made the dSAVCHKDTE a LOCAL vrbl and this
removed the
> GPF.
>
> Can anybody explain this GPF cause & cure to me ???
>
> BTW, I went over the whole module again, and 'LOCALized' all the vrbls
that
> I possibly could, and I'm back-in-action again after a 'terrifying'
morning (I
> 'terrify' easily these days :)) )
>
> TIA,
>
> -Mel Smith
>
>
>
| |
|
| Ron,
Thanks for that. I'm going to be travelling for a couple of ws but it
looks like I'll have to have a 'play' with the xHarbour I downloaded some
time ago when I get back. Thanks for the help...
--
Rob Grattan
R&D Software Pty. Ltd.
| |
| Al Acker 2004-11-27, 3:55 am |
| Klas,
This goes way back to when I wrote my book on Memory Management in Clipper.
I talk about ways to keep the symbol table low. Think David must have read
my book <g>.
Al
--
Al Acker, President
Acker Consulting, Inc.
mailto:al@thexbasefiles.com
http://www.ackerconsulting.com
"Klas Engwall" <klas.engwall@nospam.please> wrote in message
news:41a29ac4.369097524@nntpserver.swip.net...
> Tom,
>
>
> According to David Lyon at CA it is not the .OBJ file size itself but
> the size of the symbol table (reported at the end of the compilation)
> that must not exceed 64 KB. Although your suggestion can be used as an
> approximate rule of thumb it is in reality unnecessarily restrictive.
>
> This is what David said on the Clipper forum on Compuserve a long time
> ago:
>
> "CA-Clipper is able to properly access a symbol table of up to 64
> KBytes at runtime. Impirically keeping compiled target .OBJ file size
> below 64 KBytes makes it impossible to accidentally exceed this
> benchmark limitation. (An .OBJ can obviously sometimes be quite a lot
> larger than 64 KBytes without exceeding this symbol table size
> benchmark limitation.)"
>
> Regards,
> Klas
>
> -------
> klas dot engwall at engwall dot com
>
> Spammers, please use this address :-) mailto:postmaster@[127.0.0.1]
| |
|
| Ron,
Thanks for the prompt reply. As usual, answers prompt more questions...:
- Silverclip is a Comms library for accessing the Serial Port/modems. I
think there are comms functions in Clipper Tools so I should be ok?
- Not sure what you mean by recompiling the C code - recompiling with what -
a later version of the Microsoft C compiler?
- Sorry - S&R? Syntax and ?? Could you elucidate?
--
Rob Grattan
R&D Software Pty. Ltd.
| |
| Klas Engwall 2004-11-29, 3:55 pm |
| Tom,
>Beware of .obj Files > 64 KB : split .prg into multiple parts
According to David Lyon at CA it is not the .OBJ file size itself but
the size of the symbol table (reported at the end of the compilation)
that must not exceed 64 KB. Although your suggestion can be used as an
approximate rule of thumb it is in reality unnecessarily restrictive.
This is what David said on the Clipper forum on Compuserve a long time
ago:
"CA-Clipper is able to properly access a symbol table of up to 64
KBytes at runtime. Impirically keeping compiled target .OBJ file size
below 64 KBytes makes it impossible to accidentally exceed this
benchmark limitation. (An .OBJ can obviously sometimes be quite a lot
larger than 64 KBytes without exceeding this symbol table size
benchmark limitation.)"
Regards,
Klas
-------
klas dot engwall at engwall dot com
Spammers, please use this address :-) mailto:postmaster@[127.0.0.1]
| |
| Al Acker 2004-11-29, 3:55 pm |
| Klas,
This goes way back to when I wrote my book on Memory Management in Clipper.
I talk about ways to keep the symbol table low. Think David must have read
my book <g>.
Al
--
Al Acker, President
Acker Consulting, Inc.
mailto:al@thexbasefiles.com
http://www.ackerconsulting.com
"Klas Engwall" <klas.engwall@nospam.please> wrote in message
news:41a29ac4.369097524@nntpserver.swip.net...
> Tom,
>
>
> According to David Lyon at CA it is not the .OBJ file size itself but
> the size of the symbol table (reported at the end of the compilation)
> that must not exceed 64 KB. Although your suggestion can be used as an
> approximate rule of thumb it is in reality unnecessarily restrictive.
>
> This is what David said on the Clipper forum on Compuserve a long time
> ago:
>
> "CA-Clipper is able to properly access a symbol table of up to 64
> KBytes at runtime. Impirically keeping compiled target .OBJ file size
> below 64 KBytes makes it impossible to accidentally exceed this
> benchmark limitation. (An .OBJ can obviously sometimes be quite a lot
> larger than 64 KBytes without exceeding this symbol table size
> benchmark limitation.)"
>
> Regards,
> Klas
>
> -------
> klas dot engwall at engwall dot com
>
> Spammers, please use this address :-) mailto:postmaster@[127.0.0.1]
| |
| Klas Engwall 2004-11-29, 3:55 pm |
| Al,
>This goes way back to when I wrote my book on Memory Management in Clipper.
>I talk about ways to keep the symbol table low. Think David must have read
>my book <g>.
Yeah, who knows? Provided he could find that particular piece of info
in it, of course. Books without indexes, bah! <BG>
Klas
-------
klas dot engwall at engwall dot com
Spammers, please use this address :-) mailto:postmaster@[127.0.0.1]
|
|
|
|
|