Recent

Author Topic: FreeMem A/V in NTDLL  (Read 4650 times)

FrozenStar

  • Newbie
  • Posts: 2
FreeMem A/V in NTDLL
« on: April 02, 2016, 10:48:25 pm »
Hello,

I'm trying to port a DLL from Delphi to FreePascal at the moment and I'm encountering some unforeseen trouble.

The DLL does the following:
1) The DLL gets injected into a Win32 application using CreateRemoteThread.
2) "DLLMain" allocates a console, stores some stuff in global variables and installs 2 API hooks (kernel32.GetSystemTimeAsFileTime and ntdll.ZwSetInformationThread). The hooking allocates some memory using GetMem to later undo the hook.
3) The initial thread ends.
4) At some point the GetSystemTimeAsFileTime hook is called and attempts to uninstall the hook, freeing the allocated memory.
5) SysFreeMem -> SysFreeMem_Fixed -> "deallocated in wrong thread!" waitfree_fixed -> entercriticalsection(heap_lock) -> ... -> ntdll.RtlEnterCriticalSection -> dereferences null pointer, application crashes.

What's going wrong here? I doubt it's impossible to free memory that was allocated by a thread that ended? The same code works fine when compiled with Delphi XE2.

Thaddy

  • Hero Member
  • *****
  • Posts: 10276
Re: FreeMem A/V in NTDLL
« Reply #1 on: April 03, 2016, 10:03:02 am »
It is possibly a memory manager issue.
Try cmem as the memory manager (as the first unit in project file). cmem is basically a simple heap memory manager that does no sub allocations.
See if it helps.
I am more like donkey than shrek

FrozenStar

  • Newbie
  • Posts: 2
Re: FreeMem A/V in NTDLL
« Reply #2 on: April 03, 2016, 04:03:39 pm »
Yeah, that solved it. I guess the internal memory manager cannot cope with circumstances such as mine.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8572
  • FPC developer.
Re: FreeMem A/V in NTDLL
« Reply #3 on: April 03, 2016, 04:24:18 pm »
The internal memory manager is optimized for threaded usage, and therefore requires TLS. These TLS vars are automatically generated when creating a class with TThread

IIRC it is possible to initialize externally created threads with the required TLS, see http://wiki.freepascal.org/Multithreaded_Application_Tutorial#External_threads

Thaddy

  • Hero Member
  • *****
  • Posts: 10276
Re: FreeMem A/V in NTDLL
« Reply #4 on: April 09, 2016, 03:41:14 pm »
Marco, in the case of hooking on such a low level it doesn't matter too much if you can circumvent the standard memorymanager problems regarding threading. Such a situation is better solved by keeping as close to the OS memorymanager as possible. Which is the case with cmem. I have run into this multiple times, hence I always chose the easy way out ;) >:D
I am more like donkey than shrek

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8572
  • FPC developer.
Re: FreeMem A/V in NTDLL
« Reply #5 on: April 09, 2016, 04:08:46 pm »
Marco, in the case of hooking on such a low level it doesn't matter too much if you can circumvent the standard memorymanager problems regarding threading. Such a situation is better solved by keeping as close to the OS memorymanager as possible. Which is the case with cmem. I have run into this multiple times, hence I always chose the easy way out ;) >:D

Everytime I went that route because of similar considerations it turned out to be a problem in my own code. So I'm now extremely wary of such claim unless accompanied with hard evidence.

Sure any mistake might make some behaviour go away because you change memory layouts. The bug that caused them is still there though.

Thaddy

  • Hero Member
  • *****
  • Posts: 10276
Re: FreeMem A/V in NTDLL
« Reply #6 on: April 09, 2016, 04:53:34 pm »
Yes, but you seem to be unaware that the default heapmanager from the OS is - under linux and windows - already as good as threadsafe. The FPC and Delphi Pascal community feels they should bolt on a suballocator on top of that memorymanager that needs to be made threadsafe in itself. Bit of a double job. And highly suspect.
I am not going to blast the mm from fpc for the umptieth time, but simply refer to the compiler shootouts: FPC consistently scores high on efficient memory use, but at the cost of speed. And in many cases at the cost of efficient threadhandling.
I am more like donkey than shrek

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8572
  • FPC developer.
Re: FreeMem A/V in NTDLL
« Reply #7 on: April 09, 2016, 06:22:43 pm »
Yes, but you seem to be unaware that the default heapmanager from the OS is - under linux and windows - already as good as threadsafe.

Threadsafe and thread optimized are two different things.

Quote
The FPC and Delphi Pascal community feels they should bolt on a suballocator on top of that memorymanager that needs to be made threadsafe in itself. Bit of a double job. And highly suspect.
I am not going to blast the mm from fpc for the umptieth time, but simply refer to the compiler shootouts: FPC consistently scores high on efficient memory use, but at the cost of speed. And in many cases at the cost of efficient threadhandling.

You were talking about problems in a thread about problems. Now suddenly it is only performance degradation, which is a nuisance at best, not a problem.

So basically you got nothing but vague (and possibly selected) benchmark issues.

Btw, the OS memory manager is sharemem not cmem. Cmem is the C runtime memory allocator.

Thaddy

  • Hero Member
  • *****
  • Posts: 10276
Re: FreeMem A/V in NTDLL
« Reply #8 on: April 10, 2016, 05:18:35 pm »
Nope. sharemem is windows specific, even borland and children specific and is an interface to share memory between threads within the same process, including reference counted things afaik, but so is COM memory marshalling under windows, which has the benefit that can also marshal memory between processes if these processes use com.
cmem is in most cases - on most platforms - simply an interface to the OS heap manager. Therefor it is more likely to do not cause problems. The standard memorymanager from fpc (and to a lesser extend, but similar delphi's) is likely to cause problems once fragmentation becomes an issue, especially on multi-processor systems. The OS heap manager on the other hand will cost you more memory for the same task, but is tightly bolted on the allocation granularity of the OS.
I am more like donkey than shrek

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8572
  • FPC developer.
Re: FreeMem A/V in NTDLL
« Reply #9 on: April 10, 2016, 05:27:36 pm »
Nope. sharemem is windows specific,

So is whatever is behind cmem.

Quote
even borland and children specific and is an interface to share memory between threads within the same process, including reference counted things afaik, but so is COM memory marshalling under windows, which has the benefit that can also marshal memory between processes if these processes use com.

The whole remark about threading is about having memory manager state per thread, thus not having to enter a global lock for each and every allocation. It has nothing to do with threadsafety

Quote
cmem is in most cases - on most platforms - simply an interface to the OS heap manager. Therefor it is more likely to do not cause problems. The standard memorymanager from fpc (and to a lesser extend, but similar delphi's) is likely to cause problems once fragmentation becomes an issue,

On an average *nix, cmem has no more OS support than FPC's, so you may elaborate on this.

In theory per thread state means that not all state is centralized and thus block reusage is not 100% optimal. But I never have seen non border cases where it actually matters.

Quote
especially on multi-processor systems. The OS heap manager on the other hand will cost you more memory for the same task, but is tightly bolted on the allocation granularity of the OS.

Again: elaborate in the context of the C memory manager on say FreeBSD or Linux? Where is this holy "OS" tie-in? Both allocators (FPC and cmem) allocate from kernel using mmap.
« Last Edit: April 11, 2016, 12:27:13 pm by marcov »

 

TinyPortal © 2005-2018