[fpc-pascal] Debug information

2012-09-11 Thread Rainer Stratmann
I found out that there is no line information shown (-gl) if an error occurs 
(more or less shortly) after the program loads a dynamic library.

This same behaviour happens with fpc version 2.4.2-0 and 2.6.0.

If no library is loaded line information is shown.
The error adresses are the same in both cases.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Debug information

2012-09-11 Thread Mark Morgan Lloyd

Rainer Stratmann wrote:
I found out that there is no line information shown (-gl) if an error occurs 
(more or less shortly) after the program loads a dynamic library.


This same behaviour happens with fpc version 2.4.2-0 and 2.6.0.

If no library is loaded line information is shown.
The error adresses are the same in both cases.


What OS? Are you expecting a line number associated with code in the 
calling program or the .DLL/.so? What has caused the error- is the 
calling convention etc. correct?


--
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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Debug information

2012-09-11 Thread Rainer Stratmann
Am Tuesday 11 September 2012 12:05:02 schrieb Mark Morgan Lloyd:
 Rainer Stratmann wrote:
  I found out that there is no line information shown (-gl) if an error
  occurs (more or less shortly) after the program loads a dynamic library.
 
  This same behaviour happens with fpc version 2.4.2-0 and 2.6.0.
 
  If no library is loaded line information is shown.
  The error adresses are the same in both cases.

 What OS?
Linux
 Are you expecting a line number associated with code in the 
 calling program or the .DLL/.so?
Expecting: line xxx of yyy.pas
But when loading a library only adresses are shown.
 What has caused the error
simple access violation
 - is the calling convention etc. correct?
I hope so because the program runs 24/7 in some places in eurpoe.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Debug information

2012-09-11 Thread Rainer Stratmann
Am Tuesday 11 September 2012 12:05:02 schrieb Mark Morgan Lloyd:
 Are you expecting a line number associated with code in the
 calling program or the .DLL/.so?
By now only the main program if affected.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Debug information

2012-09-11 Thread Martin

On 11/09/2012 10:28, Rainer Stratmann wrote:

I found out that there is no line information shown (-gl) if an error occurs
(more or less shortly) after the program loads a dynamic library.

This same behaviour happens with fpc version 2.4.2-0 and 2.6.0.

If no library is loaded line information is shown.
The error adresses are the same in both cases.



This is about debug info written by DumpStack or similar (written by 
the exe itself, to the console)?


Or debug info shown by gdb using bt?
If the first, does the latter work?

As from your other replies, the exception occurs in your pascal code. 
But is this code in a callback from the DLL? (This would mean that 
stackframes of the DLL exist, and they have no line info)
Or could for any other reason (including compiled with optimization) 
there be a stackframe (just one) that has no line info?


IIRC the line-info on stacktraces is only displayed until the very first 
time a line without info is discovered.

That is:
1) If within the current stackdump a line without info is discovered, 
then no further line will be attempted to be resolved (even if info 
could be available)
2) If in a previous dump, such a line was discovered, then in any 
further dump (even though unrelated) no line info is printed.


In Lazarus the leak view, can attempt to resolve such traces. It 
requires the exact exe with debug info.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


[fpc-pascal] Constant of 2D array

2012-09-11 Thread Felipe Monteiro de Carvalho
Hello,

Can I write constants of a 2D array? I am trying to convert some C++
code which uses this ... so far I tryed:

const number_return_map: array[0..7][0..7] of U8 =
(
  ( 15, 14, 13, 12, 11, 10,  9,  8 ),
  ( 14,  0,  1,  3,  6, 10, 10,  9 ),
  ( 13,  1,  2,  4,  7, 11, 11, 10 ),
  ( 12,  3,  4,  5,  8, 12, 12, 11 ),
  ( 11,  6,  7,  8,  9, 13, 13, 12 ),
  ( 10, 10, 11, 12, 13, 14, 14, 13 ),
  (  9, 10, 11, 12, 13, 14, 15, 14 ),
  (  8,  9, 10, 11, 12, 13, 14, 15 )
);

but it stops between the two [0..7] requesting a of, which indicates
that it does not want a 2D array but expects a 1D array only.

-- 
Felipe Monteiro de Carvalho
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Constant of 2D array

2012-09-11 Thread Vincent Snijders
2012/9/11 Felipe Monteiro de Carvalho felipemonteiro.carva...@gmail.com:
 Hello,

 Can I write constants of a 2D array? I am trying to convert some C++
 code which uses this ... so far I tryed:

 const number_return_map: array[0..7][0..7] of U8 =

const number_return_map: array[0..7,0..7] of byte =

Vincent
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Constant of 2D array

2012-09-11 Thread Felipe Monteiro de Carvalho
On Tue, Sep 11, 2012 at 2:58 PM, Vincent Snijders
vincent.snijd...@gmail.com wrote:
 const number_return_map: array[0..7,0..7] of byte =

Ah, nice, thanks =) Now it works... and the syntax is almost the same
as in C++ which facilitates the conversion

-- 
Felipe Monteiro de Carvalho
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Constant of 2D array

2012-09-11 Thread Alexander Shishkin

11.09.2012 16:51, Felipe Monteiro de Carvalho пишет:

Hello,

Can I write constants of a 2D array? I am trying to convert some C++
code which uses this ... so far I tryed:

const number_return_map: array[0..7][0..7] of U8 =
(
   ( 15, 14, 13, 12, 11, 10,  9,  8 ),
   ( 14,  0,  1,  3,  6, 10, 10,  9 ),
   ( 13,  1,  2,  4,  7, 11, 11, 10 ),
   ( 12,  3,  4,  5,  8, 12, 12, 11 ),
   ( 11,  6,  7,  8,  9, 13, 13, 12 ),
   ( 10, 10, 11, 12, 13, 14, 14, 13 ),
   (  9, 10, 11, 12, 13, 14, 15, 14 ),
   (  8,  9, 10, 11, 12, 13, 14, 15 )
);

but it stops between the two [0..7] requesting a of, which indicates
that it does not want a 2D array but expects a 1D array only.



No of required by array syntax. But array may be multidimensional.
Should be const number_return_map: array[0..7] of array [0..7] of U8 ...
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Debug information

2012-09-11 Thread Rainer Stratmann
Am Tuesday 11 September 2012 14:16:35 schrieb Martin:
 On 11/09/2012 10:28, Rainer Stratmann wrote:
  I found out that there is no line information shown (-gl) if an error
  occurs (more or less shortly) after the program loads a dynamic library.
 
  This same behaviour happens with fpc version 2.4.2-0 and 2.6.0.
 
  If no library is loaded line information is shown.
  The error adresses are the same in both cases.

 This is about debug info written by DumpStack or similar (written by
 the exe itself, to the console)?

 Or debug info shown by gdb using bt?
 If the first, does the latter work?

?
It is a console program with graphic output to the framebuffer.
When loading succesfully the library (which depends on the x11 library) the 
framebuffer is written to an XWindow (Linux). The software runs with a plain 
(embedded) linux and also in an XWindow environment.

I have only the information of what the exe program writes down in case of an 
error. No other debug tool is used by now. Specially when the program runs 
outside it will be not easy to use additional tools, I think.

 As from your other replies, the exception occurs in your pascal code.
 But is this code in a callback from the DLL?
(Linux Library *.so)
No.
 (This would mean that 
 stackframes of the DLL exist, and they have no line info)

 Or could for any other reason (including compiled with optimization)
 there be a stackframe (just one) that has no line info?

May be.

 IIRC the line-info on stacktraces is only displayed until the very first
 time a line without info is discovered.
 That is:
 1) If within the current stackdump a line without info is discovered,
 then no further line will be attempted to be resolved (even if info
 could be available)

With not loading the library it shows all lines correctly.

 2) If in a previous dump, such a line was discovered, then in any
 further dump (even though unrelated) no line info is printed.

But why are the lines not shown if there is only one line without info?

 In Lazarus the leak view, can attempt to resolve such traces. It
 requires the exact exe with debug info.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Debug information

2012-09-11 Thread Martin

On 11/09/2012 16:07, Rainer Stratmann wrote:

Or could for any other reason (including compiled with optimization)
there be a stackframe (just one) that has no line info?

May be.


IIRC the line-info on stacktraces is only displayed until the very first
time a line without info is discovered.
That is:
1) If within the current stackdump a line without info is discovered,
then no further line will be attempted to be resolved (even if info
could be available)

With not loading the library it shows all lines correctly.

You load the lib dynamically? e.g OpenLibrary?

If it is hardlinked (procedure ... external) then this changes the exe, 
and the linker may move stuff around (including debug info, and maybe 
debug info gets broken).
On some platform samrtlinking, also has a real risk of breaking debug 
info...


If it is via OpenLibrary (e.g. you can control the usage via commandline 
switch, and therefore truly have the same exe, then I do not know...


There may be other reasons, that I do not know of.

You can always (not sure if it works for PIE / position independent) 
take the address, and have gdb check, if it can be resolved).




2) If in a previous dump, such a line was discovered, then in any
further dump (even though unrelated) no line info is printed.

But why are the lines not shown if there is only one line without info?



Missing recovery in the implementation...

Now this is from memory. double check it.  I may well remember this 
wrong.


Basically, if an error happens (exception) during a trace is printed, 
then this could lead to a new trace, a new error, a new trace ... a 
stackoverflow.
So during a trace, the pointer to the trace prog, is set to the basic 
address only prog.


Unfortunately there is no distinction between errors. So not finding a 
line is an error (IIRC it is handled the same as if dbg info is 
invalid/broken), and that is the end...


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Debug information

2012-09-11 Thread Mark Morgan Lloyd

Martin wrote:

On 11/09/2012 10:28, Rainer Stratmann wrote:
I found out that there is no line information shown (-gl) if an error 
occurs

(more or less shortly) after the program loads a dynamic library.

This same behaviour happens with fpc version 2.4.2-0 and 2.6.0.

If no library is loaded line information is shown.
The error adresses are the same in both cases.


How is the library being loaded: using FPC's dynlibs unit?

If using dynlibs, is the problem immediately after loading the library 
(.so) or is it on a call of an entry point in the library?


This is about debug info written by DumpStack or similar (written by 
the exe itself, to the console)?


Or debug info shown by gdb using bt?
If the first, does the latter work?

As from your other replies, the exception occurs in your pascal code. 
But is this code in a callback from the DLL? (This would mean that 
stackframes of the DLL exist, and they have no line info)
Or could for any other reason (including compiled with optimization) 
there be a stackframe (just one) that has no line info?


Is the DLL successfully called, does it exit predictably, and does the 
stack recover to the state it was on entry (i.e. without an extra or 
missing word)?


--
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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Debug information

2012-09-11 Thread Rainer Stratmann
Am Tuesday 11 September 2012 18:14:57 schrieb Mark Morgan Lloyd:
 Martin wrote:
  On 11/09/2012 10:28, Rainer Stratmann wrote:
  I found out that there is no line information shown (-gl) if an error
  occurs
  (more or less shortly) after the program loads a dynamic library.
 
  This same behaviour happens with fpc version 2.4.2-0 and 2.6.0.
 
  If no library is loaded line information is shown.
  The error adresses are the same in both cases.

 How is the library being loaded: using FPC's dynlibs unit?
Yes.
 If using dynlibs, is the problem immediately after loading the library
 (.so) or is it on a call of an entry point in the library?
Immediately after loading the library.
  This is about debug info written by DumpStack or similar (written by
  the exe itself, to the console)?
 
  Or debug info shown by gdb using bt?
  If the first, does the latter work?
 
  As from your other replies, the exception occurs in your pascal code.
  But is this code in a callback from the DLL? (This would mean that
  stackframes of the DLL exist, and they have no line info)
  Or could for any other reason (including compiled with optimization)
  there be a stackframe (just one) that has no line info?

 Is the DLL successfully called, does it exit predictably, and does the
 stack recover to the state it was on entry (i.e. without an extra or
 missing word)?

The program restarts some times and there is no error.
Stack recovery I don't know. I think it will be ok. How can I see that?
I use loadlibrary and freelibrary.
There are only 3 functions/procedures calling from the program. (init_proc, 
loop_proc, exit_proc).
The library calls back a procedure (add a key to a keybuffer) but in this 
procedure there is no error.
I tried safeloadlibrary but the same thing.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Debug information

2012-09-11 Thread Rainer Stratmann
Am Tuesday 11 September 2012 17:38:44 schrieb Martin:
  But why are the lines not shown if there is only one line without info?

 Missing recovery in the implementation...

 Now this is from memory. double check it.  I may well remember this
 wrong.

 Basically, if an error happens (exception) during a trace is printed,
 then this could lead to a new trace, a new error, a new trace ... a
 stackoverflow.
 So during a trace, the pointer to the trace prog, is set to the basic
 address only prog.

 Unfortunately there is no distinction between errors. So not finding a
 line is an error (IIRC it is handled the same as if dbg info is
 invalid/broken), and that is the end...

For debugging the best would be to write down as much information as possible. 
Even if it causes (eventually) more (endless) errors. Would this be possible? 
May be with a switch?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Debug information

2012-09-11 Thread Mark Morgan Lloyd

Rainer Stratmann wrote:

Am Tuesday 11 September 2012 18:14:57 schrieb Mark Morgan Lloyd:

Martin wrote:

On 11/09/2012 10:28, Rainer Stratmann wrote:

I found out that there is no line information shown (-gl) if an error
occurs
(more or less shortly) after the program loads a dynamic library.

This same behaviour happens with fpc version 2.4.2-0 and 2.6.0.

If no library is loaded line information is shown.
The error adresses are the same in both cases.

How is the library being loaded: using FPC's dynlibs unit?

Yes.

If using dynlibs, is the problem immediately after loading the library
(.so) or is it on a call of an entry point in the library?

Immediately after loading the library.


In which case I presume that you could comment out the calls to the 
entry points in the library and duplicate the problem (have you tried 
this?). Does the recently-added GetLoadError() function tell you 
anything useful?



Is the DLL successfully called, does it exit predictably, and does the
stack recover to the state it was on entry (i.e. without an extra or
missing word)?


The program restarts some times and there is no error.


If it's specifically something that happens at load time then below 
probably isn't relevant.



Stack recovery I don't know. I think it will be ok. How can I see that?


Inline assembler to dump esp and ebp.


I use loadlibrary and freelibrary.
There are only 3 functions/procedures calling from the program. (init_proc, 
loop_proc, exit_proc).
The library calls back a procedure (add a key to a keybuffer) but in this 
procedure there is no error.

I tried safeloadlibrary but the same thing.


--
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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal