0

I seem to have run in to a weird bug, which I have narrowed down to readdir() failing (and never returning) in Windows 7 & 8, but only when used with Native Messaging from a Chrome App, and only when a random but specific number of files is in the directory. The relevant C++ code is:

char            ac[10000];
std::string     sData   = "C:/TEST";
DIR *           pdir    = NULL;
struct dirent * pdirent = NULL;

if(   ( pdir = opendir(sData.c_str()) )   != NULL   ){
 while( pdirent = readdir(pdir) ){
  sReply += "|";
  sprintf(ac ,"%s" , pdirent->d_name);
  sReply += ac;
 }
 sReply += "|";
 closedir(pdir);
}

This works fine when part of a console application, and it works most of the time when part of an executable that receives a Native Message from a Chrome Packaged App - it gets and returns a text string with all file names in the directory, delimited by "|".

I wrote a test into my Chrome App, adding one file at a time between trials. It works multiple times, but then fails every time once some number of files has been added. For example, if the directory contains the files Tryc_3.txt, Tryc_4.txt, Tryc_5.txt ... Tryc_65.txt (each containing the text "test"), the directory listing works just fine. If I then add Tryc_66.txt it fails, at readdir(pdir).

I have tried different file names and directories with the same result, except the failure occurs at some other number of files. I have tried FindFirstFile, FindNextFile and FindClose with the exact same results. I have tried wrapping the whole thing with Wow64DisableWow64FsRedirection and Wow64RevertWow64FsRedirection with the exact same results. (I tried readdir_r but was unable to get it to compile, and some sites seem to say this is not available in Windows).

I am out of ideas, and am happy to hear any clues or speculation that anyone has.

I can supply the complete code, including the Chrome App, but it fairly large even after I cut as much as I can.

Why would a directory listing fail only when used with Native Messaging?

Rob W
  • 341,306
  • 83
  • 791
  • 678
DaveWalley
  • 817
  • 10
  • 22
  • It would help if you posted what `ac` is. It is an unknown and *highly* important piece of information that's missing. – PaulMcKenzie Dec 08 '14 at 21:49
  • An array of 10000 characters. Please note, this code works. – DaveWalley Dec 08 '14 at 22:04
  • Can you duplicate the issue with a simple program that does nothing except for retrieving the file names and concatenating them? What you describe is usually caused by a memory corruption bug in some other part of the program that just happens to affect this code you've posted. – PaulMcKenzie Dec 08 '14 at 22:27
  • I can duplicate the issue with a simple program that does nothing else, but it is still quite large - the minimal Chrome App seems to require main.html, background.js, app.js, a couple icons (might be optional, I am not sure), a manifest.json file for the App, a .json file for Native Messaging, and a change to the Registry, along with the C++ code. I am happy to zip it up and send it to anyone who wants it. – DaveWalley Dec 08 '14 at 22:35
  • Well, if you have the source code to readdir(), you could attempt to debug into it to determine why the crash occurs. Maybe not be able to fix it, but at least know why it happens. – PaulMcKenzie Dec 08 '14 at 22:38
  • Hadn't thought of that. Where might I find for this source code? – DaveWalley Dec 08 '14 at 22:41
  • Most compilers come with full source to their runtime, plus "debug" versions of their runtime library, so that you have access to all of the symbolic information (and line number info). I use Visual Studio, but I would believe that any compiler would have these facilities. A quick test is to just step into the function and see if you can enter it with the debugger instead of getting a mess of assembly code. – PaulMcKenzie Dec 08 '14 at 22:44
  • Extra tidbit of info: Trying system("dir") as an alternative, did not work (doesn't return, no exception thrown). For comparison, system("cd .") did work. – DaveWalley Dec 08 '14 at 23:05
  • A bit of a side question, are you using [binary mode](https://groups.google.com/a/chromium.org/forum/#!msg/chromium-extensions/AuKYO6Nn8mk/tXHclfBS78QJ) for communicating with Chrome? – Xan Dec 09 '14 at 00:26
  • Xan - please change your comment into an answer. – DaveWalley Dec 09 '14 at 02:20
  • Xan - that was it. I was completely faked out by the pattern of failures. I thought it was because I had narrowed it down by inserting and removing diagnostic messages, but it was the actual length of the messages which was determining what worked and what failed. In short, in text mode Windows was converting LF to LF/CR, which was not a problem because I safe-encoded my messages, EXCEPT the initial bytes giving the length of the messages. My real mistake was skipping a unit test under deadline pressure. Thanks all. – DaveWalley Dec 09 '14 at 03:56
  • possible duplicate of [communication between native-app and chrome-extension](http://stackoverflow.com/questions/20220668/communication-between-native-app-and-chrome-extension) – Rob W Dec 09 '14 at 12:32
  • @DaveWalley I'll vote to close as duplicate instead. If you haven't yet, show your appreciation by upvoting the question/answer Rob linked. – Xan Dec 09 '14 at 12:56
  • @RobW On a side note, why isn't your dupehammer working? – Xan Dec 09 '14 at 12:57
  • @Xan Because I don't have 1k votes in any of the initial tags of the question. – Rob W Dec 09 '14 at 12:59
  • The question is not a duplicate, although the answer may be. – DaveWalley Dec 09 '14 at 16:01

0 Answers0