Hi Harry,
While working on a predictive entry text plugin for Notepad++, I ran into a few issues that seem to be caused by the interaction between my NppPresage plugin and the NppFTP plugin that ships with the latest Notepad++ 5.9.8 Unicode release.
I wrote up a description of the issues and an initial investigation into the root cause in this thread:
http://sourceforge.net/projects/notepad-plus/forums/forum/482781/topic/5012256
I should first mention that after rebuilding the latest NppFTP sources from subversion with Code::Blocks 10.05 (MinGW), the problem I described no longer occurs.
How was NppFTP 0.24.1 built?
What SVN revision was it built from?
What compiler was it built with?
While debugging the runtime error problem described above, I used WinDBG, gdb and MS application verifier to check for errors in Notepad++ and plugins. I tracked down a couple of issues in the latest NppFTP sources. I prepared a patch that fixes an Access violation error and I am attaching it for your consideration.
The main issue I discovered was with class FTPProfile and class RefObject. FTPProfile inherits from RefObject. I guess the intent here was to endow FTPProfile objects with smart pointer functionality. However, I believe there are a couple of issues with the implementation:
34 int RefObject::Release() {
35 m_refcounter--;
36 if (!m_refcounter)
37 delete this;
38 return m_refcounter;
39 }
The first issue is that the code deletes the object at line 37, and then tries to read m_refcounter data member of the object that was just deleted.
Secondly, there is an unnecessary m_refcounter data member in FTPProfile which is not used and shadows the data member in RefObject:
33 int m_refcounter;
The attached patch resolves these issues.
Cheers,
- Matteo
Fix for access violation bug
Hi Matteo,
Thanks for the patch, next time I'll do a relase of nppftp I'll incorporate it. Thus far it has alway been built using mingw, though I cant say the exact version of GCC that I used (and I used codeblocks as my IDE). I suppose these kind of problems come and go with different compilers (and memory allocators). I've never had any issues with it myself, though this is clearly a problem. I think SVN rev 16 was used for the latest release, though I cant really be certain right now (it has been a while)