Version: 2.4.0 (using 4.4.00 (KDE 4.4.0), 4.4.0-9.fc12 Fedora) Compiler: gcc OS: Linux (x86_64) release 2.6.31.12-174.2.3.fc12.x86_64 1. Write C++ header file, use form feed character (usefull in emacs). 2. Try to import the file. -> Application will go into an infinite loop.
@Lays: Please add a test case and run it against git master or frameworks branch. The infinite loop should produce a stack trace, which should be appended to this bug.
If I'm doing this right, this bug doesn't exist anymore. I try this code: https://paste.kde.org/pzahzqsox And the class is import normally without enter in an infinite loop. Ralf, please confirm that I did right.
(In reply to Lays Rodrigues from comment #2) From the initial comment I read that the problem exists when the file contains a FormFeed not in a C/C++ string
Ralf, I can't find an example on how it's used. But in my searchs, this "\f" isn't used anymore or is used in strings. Is a break page for print papers. Look this subjetc in stack: http://stackoverflow.com/questions/3091524/what-are-carriage-return-linefeed-and-form-feed
Created attachment 98880 [details] C+Test header with form feed code
Created attachment 98883 [details] Print of the Tree View after import header example Ralf, look at the print, in the "Component view" you can see the header with a broken page, and in "Logical View" the classes that were imported. So I guess that this bug doesn't broke umbrello.
(In reply to Lays Rodrigues from comment #6) > Ralf, look at the print, in the "Component view" you can see the header with > a broken page, and in "Logical View" the classes that were imported. So I > guess that this bug doesn't broke umbrello. It looks so and we can close this bug. The open question is now to which resolved status should we set this bug and what should we place into the "version fixed in" and "latest commit" field ? If this was an issue in version 2.4.0, it must be fixed in one of the following versions. There are several options to get this info: 1. inspect the git log 2. inspect the source code to find the place, where this character may be handled and use git log -p <file> or git blame <file> to get an idea when it has been fixed. 3. The issue may be fixed in a shared library umbrello depends on like expat, Qt or KDE base libraries Unfortunally the original reporter did not provide a stack trace, which would make it much easier to find the related location.
(In reply to Ralf Habacker from comment #7) > (In reply to Lays Rodrigues from comment #6) > > Ralf, look at the print, in the "Component view" you can see the header with > > a broken page, and in "Logical View" the classes that were imported. So I > > guess that this bug doesn't broke umbrello. > > It looks so and we can close this bug. The open question is now to which > resolved status should we set this bug and what should we place into the > "version fixed in" and "latest commit" field ? If this was an issue in > version 2.4.0, it must be fixed in one of the following versions. There are > several options to get this info: > 1. inspect the git log > 2. inspect the source code to find the place, where this character may be > handled and use git log -p <file> or git blame <file> to get an idea when it > has been fixed. I had looked the code, and didn't find any place that the FF, \f or 0xC appear. And if had one, I guess that doing the git log we could find something. > 3. The issue may be fixed in a shared library umbrello depends on like > expat, Qt or KDE base libraries I guess that could be this. > > Unfortunally the original reporter did not provide a stack trace, which > would make it much easier to find the related location. Will you close this bug? I guess that "worksforme" could be good.
(In reply to Lays Rodrigues from comment #8) > Will you close this bug? I guess that "worksforme" could be good. I tried with 2.18.0 and 2.16.1. Both version does not have the issue, so I will set the "version fixed in" to the oldest version.