debugging technique

[gusl]

Dear LiveJournal Genie,

Suppose that whenever I click the mouse at a certain widget, the file named "a.txt" gets re-read into my program. I want to figure out how this is happening (i.e. which function is reading the file), so I look at the event handler for the click, but the code is unreadable, and it calls 20 other functions, each of which call 20 functions, etc.

What's a quick way to find out what function is loading the file?

Comments

[mpnolan.livejournal.com]

Maybe if you delete a.txt the program will crash and you'll get a traceback? :P

[mpnolan.livejournal.com]

It's not clear from the post if you're looking for a general solution.

[gustavolacerda.livejournal.com]

No. Let's say that a.txt not existing is equivalent to a.txt being an empty file.

Suggestions

[metaeducat10n.livejournal.com]

I assume you have access to the source for your application. If you are having trouble setting conditional breakpoints in certain library functions/classes (such as the file system), then think about creating temporary wrapper functions/classes to help you catch your case.

Such as: derive GustavoFile from File, and then make the whole system use GustavoFile. On File::Open, before you pass through to the base class check to see if the name of the file is "a.txt". You can put whatever conditional code you need in there to catch the situation in question.

A tool that will help you get a view of what's going on in some cases, though not necessarily this one, is FileMon. It doesn't generate breakpoints but can give you more information about when files are accessed and by what processes.

Re: Suggestions

[gustavolacerda.livejournal.com]

Thanks for the tip.

The problem is precisely identifying the function that opens the file. The code really is obfuscated, and reading it is an exponential problem.

Searching for the string "a.txt" gives too many hits.

Also, the whole program runs in the same process, so FileMon won't give much information.

Re: Suggestions

[gustavolacerda.livejournal.com]

Wrapper classes are a great idea, but the codebase is huge, so I would need an automated way of doing this. Any ideas?

Of course, this will only work if the code really is using File (or whatever classes I make wrappers for).

[bhudson.livejournal.com]

strace used to be the method of choice; unfortunately it has now spawned a dozen descendents whose name varies across unices. But you can start looking from there at least to find which name applies to you.

Again on Unix, you can interpose on open() and dump core there; then if you run in the debugger you will have gotten yourself a stack trace.

Modern languages are easier to do this in -- apparently you can croak() on perl in File::Open (I gather that's what the other person is saying to do); in Java you provide your own... I forgot what class opens files, but you provide your own one of those, raise an exception, and viola, a big violin.

[bhudson.livejournal.com]

Oh wait no -- metaeducat10n is saying to do the uber-painful, doesn't-often-work global search-and-replace to use your derived class (it often fails because the program uses some call somewhere that opens your file, for instance). The way that does work is to figure out how to make everybody use your new class *without knowing it*, using the magic of dynamic linkage.

[bhudson.livejournal.com]

Blah. I should shut up and drink my tea before commmenting.

"the program uses some library you have no access to that then in turn opens your file"

[gustavolacerda.livejournal.com]

Your dynamic linkage idea sounds like a great idea. It would still work if the library is within my source. Any tips on how to do that? I would need to make the create my own wrapper class named "File" which overrides the normal File class everywhere (i.e. I'd need to replace every instance of "import java.io.File" with "import gustavo.File"), EXCEPT inside itself, where I would refer to the real File class using "java.io.File".

[bhudson.livejournal.com]

No, you don't replace imports -- you replace java.io.File itself! You do this by making sure that it finds your java.io.File before any other in the classpath.

How to implement your own little java.io.File I don't quite remember. In C you have to interact directly with the dynamic linker; in Java there must be a way to open up a library (given its filename) and specifically inspect it -- I would assume this is, in fact, much better supported than in C.

[chrisamaphone]

you could grep through the source code for whatever line in Java opens a file.

[chrisamaphone]

wait, you don't have access to the source for the library calling the function? feh. java decompiler? they're all over the place...

[gustavolacerda.livejournal.com]

There are hundreds of places (lines) in the source code where files are opened.

During any given run, about 15 of those lines will be executed. And during my clicking, only 1 gets executed: namely the one I'm interested in.

[peamasii.livejournal.com]

I think the generic approach I often use is:

1. search for file-open statements in the code, note their classes/functions
2. search for the classes/functions and note where they are called from
3. add debug variables to step 2
4. repeat steps 2 and 3

Then I can at least know where the calls are being made, and I can debug any of the code along the way. It may not be that simple if any functions are called recursively of if the data structures are very complex.