David Heffernan

No. I'm not even sure what such a framework would look like. Sounds like massive overkill.

I wouldn't consider using the designer for such a thing. I would build the form dynamically in code. Your example of a dialog with a handful of checkboxes and buttons is just the Vista task dialog.

Any developer or organisation that cares about quality should be flexible enough to accept bug reports from a variety of channels. Clearly if the reporter can enter a high quality report in the project bug tracker, then that is the ideal. But in reality that is not always possible. Sometimes these reports are unclear and imprecise and the project owner has to edit the report. And sometimes the reporter just won't take the required steps. Sometimes the reporter is stubborn and for inexplicable reasons refuses to give their email address and a password to sourceforge 😉 But what developer would here of a bug in their software and not want to fix it? Any developer that is prepared to let bugs pass if they aren't in the tracker should just give up. Incidentally, it grinds my gears that Emba killed QC without transferring open reports to the replacement. On numerous occasions I have been asked by Emba staff to resubmit to QP the litany of open floating point related bugs that I submitted to QC. It makes no sense to me at all that any developers that care about quality would do that.

I'm sure you are right. It just seems weird that any git program could have performance issues when all they are doing is wrapping git.

Before knowing how to fix it, you need to know what causes the leak. That's where the minimal reproduction comes in.

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?

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.

Sometimes it takes strength to say no to some customers.

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.

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?

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.

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.

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.

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

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;