RequestDir - EXCEPTION_ACCESS_VIOLATION
BlitzMax Forums/BlitzMax Programming/RequestDir - EXCEPTION_ACCESS_VIOLATION
| ||
Can anyone see what is wrong with this code: On some directories I select I get a EXCEPTION_ACCESS_VIOLATION and the debugger drops me into system.win32.bmx: Method RequestDir$( text$,dir$ ) dir=dir.Replace( "/","\" ) Return bbSystemRequestDir( text,dir ) ' <---- HERE End Method |
| ||
Hmm seems to work ok here for all folders. Are there any specific folders that are causing it to bomb out? Maybe stick the value of CurrentDir() into a variable and print that out too before the RequestDir ? EAVs are usually but not always caused by null pointers/values etc being used in the runtime libs. |
| ||
If I use the install of Max and the standard mingw I can compile etc fine. If however I update pub and BRL with bruceys mods and recompile even this: [Code] 'Remark :) [/code] Throws a exception access violation. |
| ||
Ahhh OK. *Bruuucceeeeyyyyyyy* :-) |
| ||
Ahhh OK. I think EdzUps' post is completely unrelated to therevills. @EdzUp I just tried a clean install of 1.50. I replaced pub.mod and brl.mod with those from https://github.com/maxmods Then I installed TDM's MinGW 4.7.1, and follow the steps in my "Win32 BlitzMax with GCC 4.x - HowTo" post, which involves running a script to update libs and binaries, and sets the environment up correctly. Your basic example ran fine after this, in debug and release. |
| ||
Weird all I get is a box with EXCEPTION_ACCESS_VIOLATION plastered across it |
| ||
Strange... just ran it on my work PC and it runs fine. My work PC is running Windows 7, but my home PC (where the issue happens) is running Windows 8.1. I'll investigate tonight more... |
| ||
Hi therevills, I'm sure col knows , but there is a modern version of RequestDir which can be used in Windows enviroment. See here. As for original problem I'm not sure. I believe that RequestDir has a dependency for MSVC++ runtime library dll which might be scrooged due to some Windows update. Perhaps I'll investigate further as well :-) -Henri |
| ||
Thanks Henri, I saw that last night... but on my home PC it doesnt do anything at all which is very strange... |
| ||
It always happens for this folder: H:\Dropbox\CodeMax\LegendsOfSolitaire2\data\graphics\cards Heres a screenshot of the console: You can see it prints out testdir (Print testdir), but then the EAV :( |
| ||
Your path looks quite valid, the problem must be elsewhere. What is your current directory before and after the function call? You could set it to a fixed value just for testing. Could it be that the path contains some hidden characters? As it seems to be a DropBox path, is it possible to have some sort of sharing violation with the DropBox application (so I don't think so)? Just some thoughts... |
| ||
Can you isolate the problem to a very short independent code sample? Or happens this only within the context of your main code? |
| ||
@jsp - Heres the output of the console. Executing:untitled1.debug.exe Current dir = H:/Dropbox/CodeMax/BlitzMax/1.50/tmp Source dir = H:\Dropbox\CodeMax\LegendsOfSolitaire2\data\graphics 2 Current dir = H:/Dropbox/CodeMax/BlitzMax/1.50/tmp Save dir = H:\Back-Up Process complete @Midi - The code in the first post reproduces the issue. And heres a Gif of the issue: ![]() If I remove the second RequestDir I don't get the EAV... |
| ||
Hmmm... if I use the MaxGUI.Drivers I dont get the EAV.Import MaxGui.Drivers SuperStrict Local s$ = RequestDir("Select Source folder...",CurrentDir()) Print s$ Local e$ = RequestDir("Select End folder...",CurrentDir()) Print e$ ![]() |
| ||
In other news... ...having just looked at the code in system.win32.c, it appears that an ITEMIDLIST* is leaked every time RequestDir() is called :-) |
| ||
, it appears that an ITEMIDLIST* is leaked every time RequestDir() is called Would that cause the EAV I am seeing here? |
| ||
@Brucey I agree. I wasn't paying attention to the posters name, lol. @therevills I've updated the other file requester. Does it work for you know? If for any reason something isn't happy then it will fall back to the original requester - complete with its existing bugs :/ copied here... |
| ||
The EAV might be related to this statement by MSDN. If importing MaxGui helps then this would indicate so. You must initialize Component Object Model (COM) before you call SHBrowseForFolder. If you initialize COM using CoInitializeEx, you must set the COINIT_APARTMENTTHREADED flag in its dwCoInit parameter. You can also use CoInitialize or OleInitialize, which always use apartment threading. If you require drag-and-drop functionality, OleInitialize is recommended because it initializes the required OLE as well as COM. My second guess would be the uFlags set in the structure used for SHBrowseForFolder. @col Your new version certainly fixed something as the previous one didn't show the dialog in some conditions. -Henri |
| ||
@col - worked fine and it looks so much better! I'm just writing a little app but your RequestFolder doesnt crash and is nicer to use! Thanks! @Henri - thanks for the info. |
| ||
I'm glad that its working properly now for everyone. Enjoy :^) |