David Heffernan

A complete reproduction is surely needed here.

As an aside, can't you use a read lock here?

We can help you but we need you to provide clear information. If you want to continue posting random scraps of information that mean nothing to us (we don't have your code, or a minimal reproduction), the posts in this thread are not actionable.

As somebody who has experience debugging memory I can assure you that you are going about it the wrong way. We can for sure help, but it requires you to provide clear information and take a more structured approach. If you don't want to do that, and wish to continue with trial and error, that's fine. But please don't consume bandwidth here by posting scraps of information that means nothing to us. 

Remember that this is a public forum. Every post you make is broadcast. We don't to spend our time sifting through posts looking for the useful actionable content.

Dude, you've got a memory corruption somewhere, and the behaviour of such bugs is often not repeatable. Change something in one place, and the bug is hidden, only to pop up somewhere else.

I suggest that you stop posting here unless you have something concrete to share, and ask for help. Why are you posting you trial and error debugging in a public forum?

Do you know what valgrind is?

We are doing just that. These continued postings are just noise for us. Clearly you have a problem but unless you can provide a clear reproducible case then your latest piece of guesswork doesn't warrant an update here. 

These bugs can be hard to track down. That's why we use tools like valgrind. They track them down instantly. 

Hard to see how source tree could be slow to pull when all it is doing is shelling out to git...... 

Public service announcement:

If you don't reply to a comment that is leading nowhere, the thread just ends. 

Can't you debug the code on windows. Might be easier there and now possible because the memory model is the same. 

On Linux you can of course use valgrind. 

C# has had this cracked for more than 10 years now. Why can't Delphi get it done? 

6 minutes ago, Markus Kinzler said:

Because they see no need for impovement here, I don't think the product would be much better

Again I don't think that's true. Certainly in conversations with folks at Emba they do recognise many issues with their current product on Windows. 

20 minutes ago, Dalija Prasnikar said:

Problem is that expansion to other platforms started as customers request.

Sometimes it takes strength to say no to some customers. 

36 minutes ago, Markus Kinzler said:

But you cannot survive just with legacy! The expenses for maintenance would be copable when development would be steady in cadence with the plattforms. It is a great problem when there is the need for "reaction" in hassle.

EMBT have ti build a homogenous platform with one front end (compiler) per language and one back end per platform. The development should be decoupled ( compiler, code gen, runtime, ide).

I dispute that. I don't see anything wrong with a business model that concentrates on enhancing and developing their core market. Imagine what could have been achieved on Windows if all the resource that was used on the new platforms had been spent on Win32 and Win64? 

Remember also that the vast majority of the income is still from the Windows tools. 

1 hour ago, Dalija Prasnikar said:

Lack of resources, maybe... they have to provide proper support for platforms they have expanded to, Apple and Google have their requirements and their own toolsets and don't care much about other people's problems - with notable exceptions - but again only when it is in their own interest.

 

In that light... Windows can wait for any improvements, regardless of how many customers would actually benefit from better Windows support.

Sure it's down to a lack of resources. But that's a consequence of expanding to new platforms. Each additional platform comes with a maintenance cost.  That cost is paid for out of revenue. The bulk of the revenue comes from customers that are using the legacy platforms.  

If Emba continue to neglect their core business (Windows development tools) then eventually customers will look elsewhere.

Kinda galling to realise the effort Emba is putting in for 64 bit mobile and Mac desktop platform support (all minority user bases) and at the same time the Windows compilers (overwhelming majority user base) receive no attention at all.

What kind of business model is it to take money of your customers and then spend it on developing functionality that is not useful to the majority of your customers?

1 minute ago, Lars Fosdal said:

Since it often is the actual thread interaction in a multithreaded server that is the cause for debugging - freezing other threads would be undesirable.

I'd settle for a way to have breakpoints thread context aware so that I can choose to have breakpoints active in specific threads.  A way to easily enable/disable breakpoints per active thread context.

Stepping through execution in an interactive debugger is fine for some debugging tasks, but it's just one form of debugging. It's hopeless for debugging threading specific issues. It's the wrong tool. Lots more to debugging than interactive debugger step through. 

26 minutes ago, Alexander Elagin said:

I just spent two days debugging an innocently looking piece of code which works correctly when compliled with Delphi Win32, Delphi Win64, FPC Win64, FPC Linux64... but not with Delphi Linux64. The reason was that the Delphi Linux64 compiler for some obscure reason has SizeOf(LongWord)=8... Well, I had to look at the Delphi 10.3.1 help file, which has the following sentence: "Platform-independent integer types always have the same size, regardless of what platform you use. Platform-independent integer types include ShortInt, SmallInt, LongInt, Integer, Int64, Byte, Word, LongWord, Cardinal, and UInt64." Damn. Then I scrolled the help ten lines up and... "The platform-dependent integer types are transformed to fit the bit size of the current compiler platform. The platform-dependent integer types are NativeInt, NativeUInt, LongInt, and LongWord". Confusing, isn't it? The FPC at least is consistent.

It's not obscure if you realise that Longint and Longword map to the corresponding C++ types long int and unsigned long int whose size is determined by the platform ABI.

2 hours ago, Stefan Glienke said:

https://stackoverflow.com/a/1395915/587106

I think that post is about accessing a COM object exposed by a .net assembly. But I think that the asker is embedding the .net runtime via its COM interface. So I expect that there is a way to obtain Type and call methods on it, but who wants to scour 32kloc and learn how to use that darn thing.

Surely the entire enterprise would be easier by exposing the target code with a .net layer, e.g. a COM wrapper of the target code.

38 minutes ago, dkprojektai said:

Yes it is, But I use it just for locking. Or I'm wrong?

Yes, you are wrong. If you have two threads reading then they are not synchronisation with respect to each other. 

45 minutes ago, dkprojektai said:

Imposible. Very big project. I Think the problem is on TOmniMREW

Cut it down to a minimal repro. Although it is likely that the answer has been revealed in other comments about the misuse of the lock.

Defect in the code that isn't shown here. 

Use classic memory management. 

obj := TMyObject.Create;

try

  obj.DoSomething;

finally

  obj.Free;

end;

1 hour ago, Rudy Velthuis said:

C# delegates are terribly complex, and that is why they work the way they do. Delphi has more or less lightweight implementations for procedural and method types. Good for us.

 

So I'll repeat it:  If people want the complexity of C#, then they should use C#.

They really aren't complex at all to use. Which is my point. You are talking about the implementation details.

If you find C# complex then that's on you. Since you declared a few comments back that you didn't really have a sound grasp of C# delegates perhaps you should become knowledgeable on the subject before acting like an expert. Just a thought. 

Myself, I don't find C# delegates at all complex. It would certainly be pretty convenient if you could use anon methods as event handlers, as you can trivially do in C#. I understand why you can't in Delphi and it's too late to change now. But when you write code in other languages that don't have backwards compatability constraints, it can be irritating when you come back to Delphi. 

13 minutes ago, Rudy Velthuis said:

If people want the complexity of C#, then they should use C#

Er, the complexity is in Delphi with its multiple different procedural types. C# delegates are simple. 

2 minutes ago, Rudy Velthuis said:

Does it?

 

I haven't been using C# a lot, lately, but AFAIK, C# does not have global (non-method) functions. It may have static functions, but can you assign those to a delegate?

Can you assign its equivalent of an anonmeth to an event?

Yes to all questions. 

5 minutes ago, Rudy Velthuis said:

I don't think that makes sense.  If that type would be able to catch simple procedurals, methods and anonmeths, it would have to be prett complex, and why would you want to use a pretty complex type for even the simplest (plain procedural) function?

 

Also, an event needs two things: an object and a code pointer. It can't do without. A plain or static function does not have those, An anonymous method does not necessarily have these either.

It seems to make sense in other languages, like C# to give one example. 

The very way you talk about it is symptomatic of the problem. Talking about implementation details. Clearly there has to be an implentarion, but programmers by and large want to be shielded from these details. 

David is making a good point here. If Emba were starting from scratch here, would they end up with all these different incompatible procedural types? I doubt it.