| Summary: | tao_idl crashes/fails for me by changing include path (with same files) | ||
|---|---|---|---|
| Product: | TAO | Reporter: | Markus Stenberg <markus.stenberg> |
| Component: | IDL Compiler | Assignee: | DOC Center Support List (internal) <tao-support> |
| Status: | ASSIGNED --- | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 1.4.2 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
Oh yes, while we're at it there ARE those 2 numbers after the filename in the crashing case. It might have something to do with it or not.. -# 170 "/home/fingon/nocrypt/ace-5.4.2/TAO/orbsvcs/orbsvcs/CosEventComm.idl" +# 170 "/usr/include/orbsvcs/orbsvcs/CosEventComm.idl" 3 4 (As I quoted below, but didn't notice myself until after report - it's midnight already and been wondering at this for awhile :>) What do you mean when you say you have includes globally installed? Jeff, I guess Markus means that if the includes are installed in say /usr/include, there should be no need for doing -I <nonsense>. Looks like if the includes are installed in a system specific path, things seem to fail. Markus, it would be good to know the first error in the list of errors you get. That could give a clue to where to start looking into the problem. That 'syntax error' was the first line..
using uniq -c I get following:
1 syntax error
7 tao_idl: "frontend.idl", line 1: Statement cannot be parsed
6 tao_idl: "/usr/include/orbsvcs/orbsvcs/CosTypedEventComm.idl", line
16:Statement cannot be parsed
2 tao_idl: "/usr/include/orbsvcs/orbsvcs/CosEventComm.idl", line 34:
Statement cannot be parsed
1 tao_idl: "/usr/include/orbsvcs/orbsvcs/CosEventComm.idl", line 35:
Statement cannot be parsed
4 tao_idl: "/usr/include/orbsvcs/orbsvcs/CosEventComm.idl", line 49:
Statement cannot be parsed
1 tao_idl: "/usr/include/orbsvcs/orbsvcs/CosEventComm.idl", line 70: error
in lookup of symbol: Disconnected
1 tao_idl: "/usr/include/orbsvcs/orbsvcs/CosEventComm.idl", line 143:
error in lookup of symbol: Disconnected
... (about 2 pages more, but probably not relevant)
Is there any other processing step that might explain the difference as as I
noted, the preprocessor output looks distressingly similar :) (except for those
magic numbers at end of # lines)
We have gone back and forth on this issue. There are also reasons to leave the includes the way they are. For example, someone may have installed included files in system paths as you have, then wants to download a new version of TAO. This person may very well want to compile the new version before "installing" it. With the includes using brackets, this would lead to many errors, since the old versions of the includes would get picked up first. This is why we have explicitly used quotes for these includes. The last comment is actually for 1937? As crashes are definitely not defined behavior no matter which include format you use :) No the comment is for this bug - but this bug is related to 1937. The issue here is that, changing the IDL compiler to generate bracket C++ includes for a corresponding bracket IDL include will solve this problem but it will create another. The right course of action is not so simple. Note that the erroneous behavior in this bug does not even have any C++ compilation taking place - the error happens during the handling of IDL AST -> C++ code generation (I guess). Therefore I'm bit puzzled on how the include directive change would affect how this bug happens (as opposed to 1937), as it's obviously something to do with built-in include handling of the IDL parser (or the backend that uses the IDL AST). Unless I'm missing something, it seems that the fix for this bug and for 1937 is to generate bracketed C++ includes for bracketed IDL includes, which we do not do now. After kicking this around with several folks, it seems that this will not be so bad to do, although we have decided against it in the past. It will be a fair-sized job, since bracket vs. quote info is not passed from the front end of the IDL compiler to the back end, and simply saving the file name including the brackets causes other problems. So I will get to it as soon as I can. |
Initial disclaimer: this same tao_idl binary DOES run through the rest of the idl->C generation flawlessly, produces all tests/examples in the distribution and so on as well, so this is probably some corner case. Without further ado, assuming I have very, very simple idl file which says #include "orbsvcs/orbsvcs/CosTypedEventChannelAdmin.idl" (*wow*), and I run tao_idl few times, I get following results: fingon@semedori ~/temp/src/agent/frontend>tao_idl -E -I ~/nocrypt/ace-5.4.2/TAO frontend.idl > prep1.txt fingon@semedori ~/temp/src/agent/frontend>tao_idl -E frontend.idl > prep2.txt fingon@semedori ~/temp/src/agent/frontend>egrep -v '^#' prep2.txt > p2.txt fingon@semedori ~/temp/src/agent/frontend>egrep -v '^#' prep1.txt > p1.txt fingon@semedori ~/temp/src/agent/frontend>diff -u p1.txt p2.txt fingon@semedori ~/temp/src/agent/frontend> So the precompiled stuff is same, correct? (The only differences in the #-prefixed stuff are filenames, which I skipped for brevity's sake). Therefore include path did not affect anything as far as I understand it. just for completeness' sake, here's one example of what diff prep?.txt looks like (and lots of others) -# 170 "/home/fingon/nocrypt/ace-5.4.2/TAO/orbsvcs/orbsvcs/CosEventComm.idl" +# 170 "/usr/include/orbsvcs/orbsvcs/CosEventComm.idl" 3 4 But, things are stranger than they seem: fingon@semedori ~/temp/src/agent/frontend>tao_idl -I ~/nocrypt/ace-5.4.2/TAO frontend.idl fingon@semedori ~/temp/src/agent/frontend> Everything goes swimmingly well. *{C,S}.{cpp,h} files show up. But, the reason for this bugreport comes next :-> I remove the include path as it's redundant, and I have includes globally installed, and as before noted, they ARE the same - both from preprocessor's, and filesystem diff's format which I ran manually. Result, however, is very different: fingon@semedori ~/temp/src/agent/frontend>tao_idl frontend.idl >& errors.txt zsh: 31770 segmentation fault tao_idl frontend.idl >& errors.txt fingon@semedori ~/temp/src/agent/frontend>head errors.txt syntax error .. lots of errors, staring at first module/exception definition, and going on for 150 lines or so. This happens quite consistently in this sample (by altering the system-include I use the program either crashes or produces lots of errors as output, when from /usr/include, and works ok whem -I with my homedir installation is added). The tao_idl -E does not show any reason for this behavior. Am I missing some processing step, or is the behavior simply tied to the filenames in the #s? Seems somewhat unlikely.