Fpc Access Violation if AppConfigDir doesn't exist.

classic Classic list List threaded Threaded
83 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Sven Barth-2
Am 11.02.2013 13:06, schrieb Giuliano Colla:

> Il 11/02/2013 12:35, Michael Van Canneyt ha scritto:
>>
>>
>> On Mon, 11 Feb 2013, Giuliano Colla wrote:
>>
>>> Il 11/02/2013 09:21, Michael Van Canneyt ha scritto:
>>>>
>>>>
>>>> On Mon, 11 Feb 2013, Giuliano Colla wrote:
>>>>
>>>>> 3) But if also the *path* to the file doesn't yet exist, it just
>>>>> crashes without rising an exception that the user application can
>>>>> handle somehow.
>>>>
>>>> This is incorrect. It does tell you why it fails.
>>>>
>>>>>
>>>>> This is rather unpleasant, because the path provided by
>>>>> GetAppConfigXx does usually exist, so you have an application
>>>>> which 99% of the times works just fine, and 1% of the times
>>>>> crashes without telling why.
>>>>
>>>> It tells you *exactly* why it 'crashes':
>>>>
>>>> home: >./ti
>>>> An unhandled exception occurred at $000000000042AE87:
>>>> EFCreateError: Unable to create file "/tmp/path/to/nothing.txt"
>>>>   $000000000042AE87
>>>>
>>>
>>> This is true only if you invoke the program from command line, which
>>> is something the end user will never do.
>>
>> That is not the problem of TIniFile, but of the application programmer.
>>
>> TIniFile properly reports any error, as it should, with an exception.
>> It is always up to the application programmer to deal with such cases.
>>
>> That this is sometimes tricky in a GUI application, cannot be helped.
>>
>
> It can be helped both by reducing the likelihood of the event, as
> you've done, and by not suggesting to use in that case a try..finally
> construct in a GUI application, which would mask the errors.
The "try..finally" itself will not mask the error. The error will
propagate to the next surrounding "try..except" handler (executing the
code in all finally sections it encounters) and normally this will
result in a dialog being displayed (if you did not change
Application.OnException). It could be however that you try to create the
configuration file when the usage of GUI is no longer possible (I don't
know).

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Graeme Geldenhuys-3
In reply to this post by Giuliano Colla
On 2013-02-11 11:29, Giuliano Colla wrote:
>
> This is true only if you invoke the program from command line, which is
> something the end user will never do.


Wrong. This is something you are doing wrong in your GUI application
then. I have loads of fpGUI 'gui' applications, that report exceptions
just fine to the use - no matter how they launched that application.


Regards,
  - Graeme -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Michael Van Canneyt
In reply to this post by Giuliano Colla


On Mon, 11 Feb 2013, Giuliano Colla wrote:

>>>
>>> This is true only if you invoke the program from command line, which is
>>> something the end user will never do.
>>
>> That is not the problem of TIniFile, but of the application programmer.
>>
>> TIniFile properly reports any error, as it should, with an exception.
>> It is always up to the application programmer to deal with such cases.
>>
>> That this is sometimes tricky in a GUI application, cannot be helped.
>>
>
> It can be helped both by reducing the likelihood of the event, as you've
> done, and by not suggesting to use in that case a try..finally construct in a
> GUI application, which would mask the errors.
> This suggestion comes historically from Delphi literature, but fpc/Lazarus
> developers should never forget that they're smarter than Delphi people. ;-)

I didn't suggest anything. I wrote 'deal with such cases'.
How, this I leave up to the programmer.

But I will say this:
trying to format the user's harddrive or attempt to fry his monitor is
usually the wrong approach ;)

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Mark Morgan Lloyd-5
In reply to this post by Giuliano Colla
Giuliano Colla wrote:

> Il 11/02/2013 12:40, Mark Morgan Lloyd ha scritto:
>> Giuliano Colla wrote:
>>
>>> However, what I've learned from this episode is that while attempting
>>> to save configuration data using TINIFile on program termination you
>>> should never use a try..finally construct, as it's suggested
>>> everywhere, but rather a try..except (or both). Otherwise you'll
>>> never be able to catch possible errors.
>>
>> I'd suggest that there are two separate cases here. In the first case,
>> near the start of a program you decide whether there is a preexisting
>> .ini file, create it if not, and if necessary update it to contain
>> e.g. the default name of a backend server. In the second case, at the
>> the end of a program run you save the current session's state.
>>
> I was speaking of the second case(saving configuration data to your .ini
> file).
> When attempting to load configuration data, a try..finally is ok. If no
> configuration data are available you already have a built-in mechanism
> to provide default values.
> But when attempting to save the current session's state at the end of
> the program, a try..finally will mask any error, and possibly lead to an
> unpleasant lock up.

But you should have already ascertained early in the program- when the
.ini was created (possibly from a template) or read- that the path etc.
was accessible. What's more you're typically doing this before the main
program logic is started, so you shouldn't get caught by finalization
that's only there to clear up after the main program.

So this is, basically, bad application coding.

Besides which, while I agree that your original point

 > It turned out that the reason was simply that the default
 > AppConfigDir (~/.config/ ) wasn't there, and therefore in the
 > two usual lines

illustrates something that is inconvenient, my understanding is that
different distreaux (not to mention the preference of different system
owners) use ~/.config to a varying extent. If anything, it is the fault
of AppConfigDir for indicating a directory without raising an exception
pointing out that it doesn't yet exist :-)

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Giuliano Colla
In reply to this post by Michael Van Canneyt
On 02/11/2013 01:57 PM, Michael Van Canneyt wrote:

>
>
> On Mon, 11 Feb 2013, Giuliano Colla wrote:
>> It can be helped both by reducing the likelihood of the event, as
>> you've done, and by not suggesting to use in that case a try..finally
>> construct in a GUI application, which would mask the errors.
>> This suggestion comes historically from Delphi literature, but
>> fpc/Lazarus developers should never forget that they're smarter than
>> Delphi people. ;-)
>
> I didn't suggest anything. I wrote 'deal with such cases'. How, this I
> leave up to the programmer.
>

I wasn't speaking of you. You didn't. But too many examples show it that
way. Programmers are influenced by examples.

> But I will say this: trying to format the user's harddrive or attempt
> to fry his monitor is usually the wrong approach ;)
>

Creating a .config/ directory is somehow more in the natural programming
practice, than formatting user's hard drive, or frying his monitor.
We'll leave those practice to Redmond developers....

Giuliano

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Giuliano Colla
In reply to this post by Graeme Geldenhuys-3
On 02/11/2013 01:34 PM, Graeme Geldenhuys wrote:
> On 2013-02-11 11:29, Giuliano Colla wrote:
>> This is true only if you invoke the program from command line, which is
>> something the end user will never do.
>
> Wrong. This is something you are doing wrong in your GUI application
> then. I have loads of fpGUI 'gui' applications, that report exceptions
> just fine to the use - no matter how they launched that application.
>
I agree with you. I just followed blindly the myriad of examples which
surround with a try..finally the statements after a TIniFile.Create, to
ensure that TIniFile.Free is executed, forgetting that in a GUI
application this is not the proper way to do it.
With a try..except any error in between would be properly handled, and
Free may be called safely as required.

Giuliano




_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

DaWorm
Lost in the shuffle, wasn't this originally found in Lazarus?  Sounds like a bug report for incorrect handling of INI files when the config directory is missing needs to be filed in their bug tracker.

Jeff.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Sven Barth-2
In reply to this post by Mark Morgan Lloyd-5
On 11.02.2013 15:30, Mark Morgan Lloyd wrote:
> If anything, it is the fault
> of AppConfigDir for indicating a directory without raising an exception
> pointing out that it doesn't yet exist :-)
>

And AppConfigDir/File is documented as not guaranteeing that the path to
the directory or file exists. This also includes upper parts of the
path's tree.

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Sven Barth-2
In reply to this post by Sven Barth-2
On 11.02.2013 13:18, Sven Barth wrote:

> Am 11.02.2013 13:06, schrieb Giuliano Colla:
>> Il 11/02/2013 12:35, Michael Van Canneyt ha scritto:
>>>
>>>
>>> On Mon, 11 Feb 2013, Giuliano Colla wrote:
>>>
>>>> Il 11/02/2013 09:21, Michael Van Canneyt ha scritto:
>>>>>
>>>>>
>>>>> On Mon, 11 Feb 2013, Giuliano Colla wrote:
>>>>>
>>>>>> 3) But if also the *path* to the file doesn't yet exist, it just
>>>>>> crashes without rising an exception that the user application can
>>>>>> handle somehow.
>>>>>
>>>>> This is incorrect. It does tell you why it fails.
>>>>>
>>>>>>
>>>>>> This is rather unpleasant, because the path provided by
>>>>>> GetAppConfigXx does usually exist, so you have an application
>>>>>> which 99% of the times works just fine, and 1% of the times
>>>>>> crashes without telling why.
>>>>>
>>>>> It tells you *exactly* why it 'crashes':
>>>>>
>>>>> home: >./ti
>>>>> An unhandled exception occurred at $000000000042AE87:
>>>>> EFCreateError: Unable to create file "/tmp/path/to/nothing.txt"
>>>>>   $000000000042AE87
>>>>>
>>>>
>>>> This is true only if you invoke the program from command line, which
>>>> is something the end user will never do.
>>>
>>> That is not the problem of TIniFile, but of the application programmer.
>>>
>>> TIniFile properly reports any error, as it should, with an exception.
>>> It is always up to the application programmer to deal with such cases.
>>>
>>> That this is sometimes tricky in a GUI application, cannot be helped.
>>>
>>
>> It can be helped both by reducing the likelihood of the event, as
>> you've done, and by not suggesting to use in that case a try..finally
>> construct in a GUI application, which would mask the errors.
> The "try..finally" itself will not mask the error. The error will
> propagate to the next surrounding "try..except" handler (executing the
> code in all finally sections it encounters) and normally this will
> result in a dialog being displayed (if you did not change
> Application.OnException). It could be however that you try to create the
> configuration file when the usage of GUI is no longer possible (I don't
> know).

Just to prove my point: I wrote the following little test program in
Lazarus. Add a button to a empty form and assign the OnCreate and
OnDestroy events of the form and the OnClick event of the button and add
the following code to them:

=== snippet begin ===


procedure TForm1.FormCreate(Sender: TObject);
begin
   try
     raise Exception.Create('FormCreate');
   finally
     MessageDlg('FormCreate Finally', mtInformation, [mbOK], 0);
   end;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
   try
     raise Exception.Create('Button1Click');
   finally
     MessageDlg('Button1Click Finally', mtInformation, [mbOK], 0);
   end;
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
   try
     raise Exception.Create('FormDestroy');
   finally
     MessageDlg('FormDestroy Finally', mtInformation, [mbOK], 0);
   end;
end;

=== snippet end ===

If you now run the application (for now I assume you run it without a
debugger or outside the IDE) you first get the "FormCreate Finally"
dialog, then a "Exception "FormCreate" occured" dialog and then the form
will be display. An analogous event will happen if you click the button
and as well when you close the form.

So it would be nice if you'd show where exactly no error message is
displayed for you (preferrably with a compiling code example).

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Mattias Gaertner
In reply to this post by Sven Barth-2
On Mon, 11 Feb 2013 17:02:39 +0100
Sven Barth <[hidden email]> wrote:

> On 11.02.2013 15:30, Mark Morgan Lloyd wrote:
> > If anything, it is the fault
> > of AppConfigDir for indicating a directory without raising an exception
> > pointing out that it doesn't yet exist :-)
> >
>
> And AppConfigDir/File is documented as not guaranteeing that the path to
> the directory or file exists. This also includes upper parts of the
> path's tree.

And here is an example, what happens when a program blindly forces
directories:

http://www.administrator.de/images/content/e06eaa5bdbdca8c9602d9d0f7c5b4e09-1.gif

It seems some system variables under Windows sometimes contain
gibberish. But that's off topic.

Mattias
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Sven Barth-2
On 11.02.2013 17:16, Mattias Gaertner wrote:

> On Mon, 11 Feb 2013 17:02:39 +0100
> Sven Barth <[hidden email]> wrote:
>
>> On 11.02.2013 15:30, Mark Morgan Lloyd wrote:
>>> If anything, it is the fault
>>> of AppConfigDir for indicating a directory without raising an exception
>>> pointing out that it doesn't yet exist :-)
>>>
>>
>> And AppConfigDir/File is documented as not guaranteeing that the path to
>> the directory or file exists. This also includes upper parts of the
>> path's tree.
>
> And here is an example, what happens when a program blindly forces
> directories:
>
> http://www.administrator.de/images/content/e06eaa5bdbdca8c9602d9d0f7c5b4e09-1.gif

Hui O.o It shows nicely that NTFS and Windows support Unicode characters :P

> It seems some system variables under Windows sometimes contain
> gibberish. But that's off topic.

Either that or the application did use the corresponding APIs correctly...

Regards,
Sven

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Giuliano Colla
In reply to this post by DaWorm
On 02/11/2013 04:45 PM, DaWorm wrote:
> Lost in the shuffle, wasn't this originally found in Lazarus?  Sounds
> like a bug report for incorrect handling of INI files when the config
> directory is missing needs to be filed in their bug tracker.
>

INI files and related stuff are part of the fcl library
(packages/fcl-base), not of the Lazarus library.

Giuliano

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

DaWorm
On Mon, Feb 11, 2013 at 1:48 PM, Giuliano Colla <[hidden email]> wrote:
On 02/11/2013 04:45 PM, DaWorm wrote:
Lost in the shuffle, wasn't this originally found in Lazarus?  Sounds like a bug report for incorrect handling of INI files when the config directory is missing needs to be filed in their bug tracker.


INI files and related stuff are part of the fcl library (packages/fcl-base), not of the Lazarus library.

Sorry, went back and look, I misread "a Lazarus application" as "the Lazarus application" and thought it was Lazarus itself saving its settings.

As Emily Littella used to say, Never Mind.

Jeff.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Giuliano Colla
In reply to this post by Sven Barth-2
On 02/11/2013 05:12 PM, Sven Barth wrote:

> On 11.02.2013 13:18, Sven Barth wrote:
>> Am 11.02.2013 13:06, schrieb Giuliano Colla:
>>> Il 11/02/2013 12:35, Michael Van Canneyt ha scritto:
>>>>
>>>>
>>>> On Mon, 11 Feb 2013, Giuliano Colla wrote:
>>>>
>>>>> Il 11/02/2013 09:21, Michael Van Canneyt ha scritto:
>>>>>>
>>>>>>
>>>>>> On Mon, 11 Feb 2013, Giuliano Colla wrote:
>>>>>>
>>>>>>> 3) But if also the *path* to the file doesn't yet exist, it just
>>>>>>> crashes without rising an exception that the user application can
>>>>>>> handle somehow.
>>>>>>
>>>>>> This is incorrect. It does tell you why it fails.
>>>>>>
>>>>>>>
>>>>>>> This is rather unpleasant, because the path provided by
>>>>>>> GetAppConfigXx does usually exist, so you have an application
>>>>>>> which 99% of the times works just fine, and 1% of the times
>>>>>>> crashes without telling why.
>>>>>>
>>>>>> It tells you *exactly* why it 'crashes':
>>>>>>
>>>>>> home: >./ti
>>>>>> An unhandled exception occurred at $000000000042AE87:
>>>>>> EFCreateError: Unable to create file "/tmp/path/to/nothing.txt"
>>>>>>   $000000000042AE87
>>>>>>
>>>>>
>>>>> This is true only if you invoke the program from command line, which
>>>>> is something the end user will never do.
>>>>
>>>> That is not the problem of TIniFile, but of the application
>>>> programmer.
>>>>
>>>> TIniFile properly reports any error, as it should, with an exception.
>>>> It is always up to the application programmer to deal with such cases.
>>>>
>>>> That this is sometimes tricky in a GUI application, cannot be helped.
>>>>
>>>
>>> It can be helped both by reducing the likelihood of the event, as
>>> you've done, and by not suggesting to use in that case a try..finally
>>> construct in a GUI application, which would mask the errors.
>> The "try..finally" itself will not mask the error. The error will
>> propagate to the next surrounding "try..except" handler (executing the
>> code in all finally sections it encounters) and normally this will
>> result in a dialog being displayed (if you did not change
>> Application.OnException). It could be however that you try to create the
>> configuration file when the usage of GUI is no longer possible (I don't
>> know).
>
> Just to prove my point: I wrote the following little test program in
> Lazarus. Add a button to a empty form and assign the OnCreate and
> OnDestroy events of the form and the OnClick event of the button and
> add the following code to them:
>
> === snippet begin ===
>
>
> procedure TForm1.FormCreate(Sender: TObject);
> begin
>   try
>     raise Exception.Create('FormCreate');
>   finally
>     MessageDlg('FormCreate Finally', mtInformation, [mbOK], 0);
>   end;
> end;
>
> procedure TForm1.Button1Click(Sender: TObject);
> begin
>   try
>     raise Exception.Create('Button1Click');
>   finally
>     MessageDlg('Button1Click Finally', mtInformation, [mbOK], 0);
>   end;
> end;
>
> procedure TForm1.FormDestroy(Sender: TObject);
> begin
>   try
>     raise Exception.Create('FormDestroy');
>   finally
>     MessageDlg('FormDestroy Finally', mtInformation, [mbOK], 0);
>   end;
> end;
>
> === snippet end ===
>
> If you now run the application (for now I assume you run it without a
> debugger or outside the IDE) you first get the "FormCreate Finally"
> dialog, then a "Exception "FormCreate" occured" dialog and then the
> form will be display. An analogous event will happen if you click the
> button and as well when you close the form.
>
> So it would be nice if you'd show where exactly no error message is
> displayed for you (preferrably with a compiling code example).
>

I extracted from my code a minimal example, and I too can see the
exception dialog, which doesn't show in the main application.

I don't see why the extra code should create a problem, but, by adding
one piece after the other I should be able to find out where the problem
comes from. However, replacing the original try..finally with a
try..except, the main application behaves properly, but in that case
it's the application which pops up the error dialog.

Giuliano

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fpc Access Violation if AppConfigDir doesn't exist.

Sven Barth-2
On 11.02.2013 21:10, Giuliano Colla wrote:
> I don't see why the extra code should create a problem, but, by adding
> one piece after the other I should be able to find out where the problem
> comes from. However, replacing the original try..finally with a
> try..except, the main application behaves properly, but in that case
> it's the application which pops up the error dialog.

It would be nice if you could minimize the problemematic code further
step by step so that we can see what caused the "missing dialog". Maybe
it's a bug somewhere else...

Regards,
Sven

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Compiled program is a virus (seems to be internal linker problem)

Gerhard Scholz
In reply to this post by DaWorm
Platform: Win32, FPC2.7.1, Virusscanner Avira Free Antivirus

The compiled program is assumed to be a virus.

Name:TR/Crypt.XPACK.Gen2 (according to Avira, shall be a trojan)

Compile line:
 ppc386 -vv -al -CioOrt -Cs6000000        -gclt -Mobjfpc -O1 -OpPENTIUM

With the external linker ( -Xe ) the program is not a virus and works.

Shall I make a bug report from that? I think I can not produce a small test
program, the problem occurs only with one program, others do compile without
problem.

Gerhard

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Compiled program is a virus (seems to be internal linker problem)

Florian Klämpfl
Am 11.02.2013 21:22, schrieb Gerhard Scholz:

> Platform: Win32, FPC2.7.1, Virusscanner Avira Free Antivirus
>
> The compiled program is assumed to be a virus.
>
> Name:TR/Crypt.XPACK.Gen2 (according to Avira, shall be a trojan)
>
> Compile line: ppc386 -vv -al -CioOrt -Cs6000000        -gclt -Mobjfpc
> -O1 -OpPENTIUM
>
> With the external linker ( -Xe ) the program is not a virus and works.
>
> Shall I make a bug report from that?

Yes, for avira (assuming your PC is not infected) since the program is
apparently not a virus.

> I think I can not produce a small
> test program, the problem occurs only with one program, others do
> compile without problem.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Compiled program is a virus (seems to be internal linker problem)

Martin Frb
In reply to this post by Gerhard Scholz
On 11/02/2013 20:22, Gerhard Scholz wrote:

> Platform: Win32, FPC2.7.1, Virusscanner Avira Free Antivirus
>
> The compiled program is assumed to be a virus.
>
> Name:TR/Crypt.XPACK.Gen2 (according to Avira, shall be a trojan)
>
> Compile line: ppc386 -vv -al -CioOrt -Cs6000000        -gclt -Mobjfpc
> -O1 -OpPENTIUM
>
> With the external linker ( -Xe ) the program is not a virus and works.
>
> Shall I make a bug report from that? I think I can not produce a small
> test program, the problem occurs only with one program, others do
> compile without problem.

IMHO, should be reported to the AV manufacturer.

btw, if you strip debug info, is it still reported? Because Kaspersky
had/has that problem. And several other AV seems to get signatures from
the same source.


On report they updated their signatures. Apparently whitelisted. The
reported exe, now is fine. A byte by byte identical exe, with the
exception of one single digit, in a textual date string differing, is
still reported.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Compiled program is a virus (seems to be internallinker problem)

Gerhard Scholz
@Martin:

Compile line: ppc386 -vv -al -CioOrt -Cs6000000 -Mobjfpc -O1 -OpPENTIUM
(dropping the -gclt) helped.

It seems you were right.

Gerhard

----- Original Message -----
From: "Martin" <[hidden email]>
To: "FPC-Pascal users discussions" <[hidden email]>
Sent: Monday, February 11, 2013 10:08 PM
Subject: Re: [fpc-pascal] Compiled program is a virus (seems to be
internallinker problem)


> On 11/02/2013 20:22, Gerhard Scholz wrote:
>> Platform: Win32, FPC2.7.1, Virusscanner Avira Free Antivirus
>>
>> The compiled program is assumed to be a virus.
>>
>> Name:TR/Crypt.XPACK.Gen2 (according to Avira, shall be a trojan)
>>
>> Compile line:
>> ppc386 -vv -al -CioOrt -Cs6000000        -gclt -Mobjfpc -O1 -OpPENTIUM
>>
>> With the external linker ( -Xe ) the program is not a virus and works.
>>
>> Shall I make a bug report from that? I think I can not produce a small
>> test program, the problem occurs only with one program, others do compile
>> without problem.
>
> IMHO, should be reported to the AV manufacturer.
>
> btw, if you strip debug info, is it still reported? Because Kaspersky
> had/has that problem. And several other AV seems to get signatures from
> the same source.
>
>
> On report they updated their signatures. Apparently whitelisted. The
> reported exe, now is fine. A byte by byte identical exe, with the
> exception of one single digit, in a textual date string differing, is
> still reported.
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Compiled program is a virus (seems to be internallinker problem)

Gerhard Scholz
I switched to AVAST free Antivirus now, the problem does not occur here.

This is not a pascal question, but maybe can give me a hint if AVAST is good
or which software is more recommendable.
(I do not really trust the tests I find in the internet because I do not
know
who pays them)

Gerhard

----- Original Message -----
From: "Gerhard Scholz" <[hidden email]>
To: "FPC-Pascal users discussions" <[hidden email]>
Sent: Monday, February 11, 2013 11:07 PM
Subject: Re: [fpc-pascal] Compiled program is a virus (seems to be
internallinker problem)


> @Martin:
>
> Compile line: ppc386 -vv -al -CioOrt -Cs6000000 -Mobjfpc -O1 -OpPENTIUM
> (dropping the -gclt) helped.
>
> It seems you were right.
>
> Gerhard
>
> ----- Original Message -----
> From: "Martin" <[hidden email]>
> To: "FPC-Pascal users discussions" <[hidden email]>
> Sent: Monday, February 11, 2013 10:08 PM
> Subject: Re: [fpc-pascal] Compiled program is a virus (seems to be
> internallinker problem)
>
>
>> On 11/02/2013 20:22, Gerhard Scholz wrote:
>>> Platform: Win32, FPC2.7.1, Virusscanner Avira Free Antivirus
>>>
>>> The compiled program is assumed to be a virus.
>>>
>>> Name:TR/Crypt.XPACK.Gen2 (according to Avira, shall be a trojan)
>>>
>>> Compile line:
>>> ppc386 -vv -al -CioOrt -Cs6000000        -gclt -Mobjfpc -O1 -OpPENTIUM
>>>
>>> With the external linker ( -Xe ) the program is not a virus and works.
>>>
>>> Shall I make a bug report from that? I think I can not produce a small
>>> test program, the problem occurs only with one program, others do
>>> compile without problem.
>>
>> IMHO, should be reported to the AV manufacturer.
>>
>> btw, if you strip debug info, is it still reported? Because Kaspersky
>> had/has that problem. And several other AV seems to get signatures from
>> the same source.
>>
>>
>> On report they updated their signatures. Apparently whitelisted. The
>> reported exe, now is fine. A byte by byte identical exe, with the
>> exception of one single digit, in a textual date string differing, is
>> still reported.
>> _______________________________________________
>> fpc-pascal maillist  -  [hidden email]
>> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
12345