Home General

Division bny zero no longer throws an exception

edited August 2010 in General
Using D 2006, I have an app that is run via CITRIX in an loadbalancing
environment. The app ran fine for years until a few months calculations
began to fail. I tracked this down to:

A division by zero does not always thro an exception.

I found another thread where the same is discussed identifiying the
coprocessor?s exception mask being modified.

Additionally I observed, that the above only occurs after I previewed or
printed RB reports.

Does this make sense? Is there a chance, that RB modifies this mask (maybe
via DirectX)?

TIA + gts from Vienna
Bernd

Comments

  • edited August 2010
    In another thread I found, that a printer driver changed the FPU maks.

    I see that in ppPrintr.pas the EndDoc saves and restores the FPU mak.
    Shouldn?t that be enough?

    B.

  • edited August 2010
    > I see that in ppPrintr.pas the EndDoc saves and restores the FPU mak.

    Correct. That code is necessary to workaround buggy printer drivers, but it
    restores the prior state. We have not had any reports of RB causing issues
    such as you are reporting.


    --
    Nard Moseley
    Digital Metaphorsh
    www.digital-metaphors.com



    Best regards,

    Nard Moseley
    Digital Metaphors
    www.digital-metaphors.com
  • edited August 2010
    It is very weird.

    Steps to reproduce:
    - start software
    - preview report
    - execute function X --> problem occurs

    Without the preview (and preview or print is necessary, aborting after the
    autosearch-dialogs is not enough!) the problem does NOT occur. So I thought
    that the printer drivers are the cause.

    BUT: The software is launched via CITRIX by about 120 User. Actually 3
    MetaFrame servers do loadbalancing. The problem is independent of the
    server, but it does not occur for all users, even if they run the program on
    the same MF-server.

    It looks as if there are different versions of a dll loaded, one of them
    causing trouble. I have no idea how to isolate this.

    I changed the try/except to a if ... <> 0 and now the code works perfect.

    B.




  • edited August 2010
    Previewing a report will /not/ execute the ppPinter.EndDoc code and that is
    the only RB code that calls Set8087CW.

    Perhaps updating printer driver dll's for all user accounts would help.


    --
    Nard Moseley
    Digital Metaphors
    www.digital-metaphors.com



    Best regards,

    Nard Moseley
    Digital Metaphors
    www.digital-metaphors.com
  • edited August 2010
    > Previewing a report will /not/ execute the ppPinter.EndDoc code and that

    I see. When is the printer driver loaded?


    Hmmmm. Good idea.

    tx B.
  • edited August 2010
    > I see. When is the printer driver loaded?

    RB does explicitly load any drivers. RB makes Windows API calls, that can
    result in the printer driver being loaded. That can occur during design,
    preview or print,


    --
    Nard Moseley
    Digital Metaphors
    www.digital-metaphors.com



    Best regards,

    Nard Moseley
    Digital Metaphors
    www.digital-metaphors.com
This discussion has been closed.