Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2020-05

r45217 breaks Lazarus compile

14 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

C Western

Compiling Lazarus trunk with the latest fpc:

components/ideintf/propedits.pp(6019,28) Fatal: Internal error 200709171

Colin

Reply by email

C Western
to C Western
C Western wrote 5 lines
Compiling Lazarus trunk with the latest fpc: components/ideintf/propedits.pp(6019,28) Fatal: Internal error 200709171 Colin

Seems now to be fixed in a recent update. However my program now crashes on exit in CSetThreadDebugNameA. (Why is this called on exit? I don't think I create any threads on exit. This is Linux x86_64.)

Colin

Reply by email

C Western
to C Western
C Western wrote 12 lines
On 02/05/2020 10:36, C Western wrote: > Compiling Lazarus trunk with the latest fpc: > > components/ideintf/propedits.pp(6019,28) Fatal: Internal error 200709171 > > Colin Seems now to be fixed in a recent update. However my program now crashes on exit in CSetThreadDebugNameA. (Why is this called on exit? I don't think I create any threads on exit. This is Linux x86_64.) Colin

To answer my own question, it seems that pthread_setname_np, and thus CSetThreadDebugNameA must not be called with a null string.

Colin

Reply by email

Sven Barth
to C Western
C Western wrote 17 lines
On 03/05/2020 20:59, C Western wrote: > On 02/05/2020 10:36, C Western wrote: >> Compiling Lazarus trunk with the latest fpc: >> >> components/ideintf/propedits.pp(6019,28) Fatal: Internal error >> 200709171 >> >> Colin > > Seems now to be fixed in a recent update. However my program now > crashes on exit in CSetThreadDebugNameA. (Why is this called on exit? > I don't think I create any threads on exit. This is Linux x86_64.) > > Colin To answer my own question, it seems that pthread_setname_np, and thus CSetThreadDebugNameA must not be called with a null string.

I have added protections against empty strings in r45237, though I would be quite curious what already called TThread.NameThreadForDebugging considering it was implemented only recently...

Regards,
Sven

Reply by email

C Western
to Sven Barth
I have added protections against empty strings in r45237, though I would be quite curious what already called TThread.NameThreadForDebugging considering it was implemented only recently...

In fact I had added a call to pthread_setname_np in my application a while ago, and I think there was some discussion about NameThreadForDebugging in the mailing lists, possibly for a different platform, so I added it to the development version of my program.

Colin

Reply by email

Sven Barth
to C Western

C Western schrieb am Mo., 4. Mai 2020, 09:59:

Show quoted text 11 lines
> I have added protections against empty strings in r45237, though I > would be quite curious what already called > TThread.NameThreadForDebugging considering it was implemented only > recently... In fact I had added a call to pthread_setname_np in my application a while ago, and I think there was some discussion about NameThreadForDebugging in the mailing lists, possibly for a different platform, so I added it to the development version of my program.

TThread.NameThreadForDebugging is implemented for Windows, Linux and Android since the weekend.

Regards,
Sven

Reply by email

Marc Weustink
to Sven Barth
Sven Barth wrote
TThread.NameThreadForDebugging is implemented for Windows, Linux and Android since the weekend.

Just curious, why is NameThreadForDebugging used instead of simply TThread.Name ?

ForDebugging is just one of the purposes, and TThread.NameThread is double, since it is a property of a thread, what else would you give a name.

Marc

Reply by email

Sven Barth
to Marc Weustink: Just curious, why is NameThreadForDebugging used instead of simply TThread.Name ?…

Marc Weustink via fpc-devel schrieb am
Di., 5. Mai 2020, 09:27:

Show quoted text 12 lines
Sven Barth via fpc-devel wrote: > > TThread.NameThreadForDebugging is implemented for Windows, Linux and > Android since the weekend. Just curious, why is NameThreadForDebugging used instead of simply TThread.Name ? ForDebugging is just one of the purposes, and TThread.NameThread is double, since it is a property of a thread, what else would you give a name.

As Marco said, Delphi compatibility. Also debugging *is* the *only* purpose of this. Not to mention that this is a write only functionality. There is no way to retrieve the thread's name and it's also not stored anywhere on the Pascal side.

Regards,
Sven

Reply by email

Marc Weustink
to Sven Barth
Sven Barth wrote 17 lines
Marc Weustink via fpc-devel < > schrieb am Di., 5. Mai 2020, 09:27: Sven Barth via fpc-devel wrote: > > TThread.NameThreadForDebugging is implemented for Windows, Linux and > Android since the weekend. Just curious, why is NameThreadForDebugging used instead of simply TThread.Name ? ForDebugging is just one of the purposes, and TThread.NameThread is double, since it is a property of a thread, what else would you give a name. As Marco said, Delphi compatibility.

Sigh.... reading the Delphi docs now and I understand the name

Also debugging *is* the *only* purpose of this. Not to mention that this is a write only functionality. There is no way to retrieve the thread's name and it's also not stored anywhere on the Pascal side.

Not entirely true on windows. There are 2 ways to name a thread. The first is indeed for debugging only since it is passed to the debugger though some predefined exception.
The second is recently introduced by the Get/SetThreadDescription functions. The Get function can be used by other (non debugger) applications. Some applications already set the description this way.

Marc

Reply by email

Michael Van Canneyt
to Marco van de Voort
Marco van de Voort wrote 11 lines
Op 2020-05-05 om 11:08 schreef Sven Barth via fpc-devel: > > ForDebugging is just one of the purposes, and TThread.NameThread is > double, since it is a property of a thread, what else would you > give a name. > > > As Marco said, ? huh ?

Typo. Should be Michael :)

Michael.

Reply by email

Sven Barth
to Michael Van Canneyt

Michael Van Canneyt schrieb am Di., 5. Mai 2020,
11:33:

Show quoted text 18 lines
On Tue, 5 May 2020, Marco van de Voort wrote: > > Op 2020-05-05 om 11:08 schreef Sven Barth via fpc-devel: >> >> ForDebugging is just one of the purposes, and TThread.NameThread is >> double, since it is a property of a thread, what else would you >> give a name. >> >> >> As Marco said, > > ? huh ? Typo. Should be Michael :)

Eh, yes, sorry. I'm on my phone and was too lazy to check whether I had remembered the correct name or not ^^' (and it seems I didn't :P)

Regards,
Sven

Reply by email

Sven Barth
to Marc Weustink: Sigh.... reading the Delphi docs now and I understand the name Not entirely true on…

Marc Weustink via fpc-devel schrieb am
Di., 5. Mai 2020, 11:21:

Show quoted text 12 lines
> Also debugging *is* the *only* > purpose of this. Not to mention that this is a write only functionality. > There is no way to retrieve the thread's name and it's also not stored > anywhere on the Pascal side. Not entirely true on windows. There are 2 ways to name a thread. The first is indeed for debugging only since it is passed to the debugger though some predefined exception. The second is recently introduced by the Get/SetThreadDescription functions. The Get function can be used by other (non debugger) applications. Some applications already set the description this way.

Yes, but we don't provide any cross platform way to retrieve the name in that case.

Regards,
Sven

Reply by email