[Harbour] Re: Harbour "random" GPFs
Viktor Szakáts wrote: > > Lately I mentioned having "random" GPFs with my live apps > since changing to Harbour r14336. I also mentioned they are > gone. This turned out not to be true, they are still present. > And today I am the victim of this strange behavior. Since morning I am struggling to locate where it does happen. I am implementing horizontal ruler in hbIDE and have to change/add some methods in hbqt_hbqplaintextedit.cpp/.h Sometime the same code goes through and I can see main window. Then I add a variable in .h ( just add ), link it, and voila it GPFs. I did not use this variable anywhere yet. Then I delete this declaration, but still GPFs. I build clean complete Harbour, GPF vanishes, I introduce something, again GPF. Certainly I am unable to exactly locate in which circumstances and under what flow it is generated. This is on my office machine. Later I will copy these two files on my laptop and will see what is the behavior and will report here. Just today has been wasted altogether without any output. It was just to inform. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/Harbour-random-GPFs-tp4968103p4977960.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Harbour "random" GPFs
Pritpal Bedi wrote: > > And today I am the victim of this strange behavior. > Since morning I am struggling to locate where it does happen. > In continuation... Whenever I change something in hbqt_hbqplainttextedit.h ( for this matter it could be any .h in hbqt ), and compile/link the application GPF certainly appears. But if I build clean hbqt, application behaves properly. So I suspect, because .h in hbQT are subject to "moc" application, something gets weired with signal/slots addresses. It is corrected only if all moc_*.cpp's are included at once in the lib. I am not sure if this points to real cause or not, but am 100% sure that rebuild of hbQT after a change in .h ( no matter that change is only a blank line or any variable declaration which has never been used in the code ) GPF happens. After clean build, I can make any changes to .cpp without GPF's. Someone can confirm this behavior on their setup ? Or I have something terrifically mis-configured environment on my machine ? - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/Harbour-random-GPFs-tp4968103p4980417.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Harbour "random" GPFs
Viktor Szakáts wrote: > > The problem happens when >contrib\hbqt\qtgui\HBQPlainTextEdit.cpp > refers to: >#include "../hbqt_hbqplaintextedit.h" > > so, when you modify the latter, you should > manually force a rebuild on 'qtgui' lib, > otherwise you will get crashes. [ IOW this > is the 2nd case from my original mail ] > > There are many similar inclusions in hbqt > code, so most probably all "require manual > rebuild" situations can be traced back to > this cause. > Oh. Now I know why is this behavior. I am really short of insight how to solve it. Can you provide a mechanism to build indivisual hbqt* libs ? Partially it will speedup my development. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/Harbour-random-GPFs-tp4968103p5000581.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Harbour "random" GPFs
Heinz V Bergen wrote: > > Called from EXPORT(973) in ../BREXPORT.prg > Can you show the offending line code ? I suspect, you are executing the .exe from a different location other than it is intended to. Right ? Line # 973 in export.prg may provide us a clue. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/Harbour-random-GPFs-tp4968103p5003799.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Harbour "random" GPFs
Heinz V Bergen wrote: > > Error occurs on the Return() of the function and all processes within were > completed successfully. The function creates Directories, copies files, > creates an FTP script, calls external RUN to PkZip and FTP and then erases > files and removes directories, thought maybe RUN calls were the culprit, > so > I have bypassed PKZIP and FTP calls, just replacing with Copy File so > process can continue, and error still occurs. Not sure if posting function > in a usable form will be possible, but I will continue trying to narrow it > down and see if I can come up with something. One item of note though, is > that the latest SVN hbmk2 and release 2.0 hbmk2 do create different > application EXE sizes. > Then I support your concern. Because, in hbIDE also sometimes I get GPF at termination, sometimes RTE, and sometimes it terminates fine. The worst part is I do not get such error on other XP machine at office. What is wrong I could never figure out. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/Harbour-random-GPFs-tp4968103p5003966.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Harbour "random" GPFs
> In continuation... > > Whenever I change something in hbqt_hbqplainttextedit.h > ( for this matter it could be any .h in hbqt ), and compile/link > the application GPF certainly appears. > > But if I build clean hbqt, application behaves properly. > > So I suspect, because .h in hbQT are subject to "moc" application, > something gets weired with signal/slots addresses. It is corrected > only if all moc_*.cpp's are included at once in the lib. > > I am not sure if this points to real cause or not, > but am 100% sure that rebuild of hbQT after a change in .h > ( no matter that change is only a blank line or any variable > declaration which has never been used in the code ) > GPF happens. After clean build, I can make any changes to > .cpp without GPF's. > > Someone can confirm this behavior on their setup ? > Or I have something terrifically mis-configured environment > on my machine ? One problem may be that when you change a HBQT header, the related moc_*.cpp file will be rebuilt and compiled, but the related .cpp file will not be recompiled. Also, if you update an #include-d header, like hbqt.h, a full rebuild is always necessary. The fact that moc_*.cpp files are included in lib at once or one-by-one should never make any difference. They are fully independent sources. If this happened just now, there is a change to find out the exact reason: make a full rebuild with HBQT r14412, then update to latest source, do an incremental build, make a backup of all generated files (moc_*.cpp and objects), then make a rebuild and compare generated files if there is a difference. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Harbour "random" GPFs
Hi Pritpal, The problem happens when contrib\hbqt\qtgui\HBQPlainTextEdit.cpp refers to: #include "../hbqt_hbqplaintextedit.h" so, when you modify the latter, you should manually force a rebuild on 'qtgui' lib, otherwise you will get crashes. [ IOW this is the 2nd case from my original mail ] There are many similar inclusions in hbqt code, so most probably all "require manual rebuild" situations can be traced back to this cause. Viktor On 2010 Apr 29, at 18:03, Viktor Szakáts wrote: >> In continuation... >> >> Whenever I change something in hbqt_hbqplainttextedit.h >> ( for this matter it could be any .h in hbqt ), and compile/link >> the application GPF certainly appears. >> >> But if I build clean hbqt, application behaves properly. >> >> So I suspect, because .h in hbQT are subject to "moc" application, >> something gets weired with signal/slots addresses. It is corrected >> only if all moc_*.cpp's are included at once in the lib. >> >> I am not sure if this points to real cause or not, >> but am 100% sure that rebuild of hbQT after a change in .h >> ( no matter that change is only a blank line or any variable >> declaration which has never been used in the code ) >> GPF happens. After clean build, I can make any changes to >> .cpp without GPF's. >> >> Someone can confirm this behavior on their setup ? >> Or I have something terrifically mis-configured environment >> on my machine ? > > One problem may be that when you change a > HBQT header, the related moc_*.cpp file will > be rebuilt and compiled, but the related .cpp > file will not be recompiled. > > Also, if you update an #include-d header, > like hbqt.h, a full rebuild is always necessary. > > The fact that moc_*.cpp files are included in > lib at once or one-by-one should never make any > difference. They are fully independent sources. > > If this happened just now, there is a change to > find out the exact reason: make a full rebuild > with HBQT r14412, then update to latest source, > do an incremental build, make a backup of > all generated files (moc_*.cpp and objects), > then make a rebuild and compare generated > files if there is a difference. > > Viktor > ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Harbour "random" GPFs
>> The problem happens when >> contrib\hbqt\qtgui\HBQPlainTextEdit.cpp >> refers to: >> #include "../hbqt_hbqplaintextedit.h" >> >> so, when you modify the latter, you should >> manually force a rebuild on 'qtgui' lib, >> otherwise you will get crashes. [ IOW this >> is the 2nd case from my original mail ] >> >> There are many similar inclusions in hbqt >> code, so most probably all "require manual >> rebuild" situations can be traced back to >> this cause. >> > > Oh. > Now I know why is this behavior. > I am really short of insight how to solve it. > Can you provide a mechanism to build indivisual > hbqt* libs ? Partially it will speedup my development. Pls read '2. HOW TO DO A PARTIAL [RE]BUILD' in INSTALL, it should give you the necessary hints. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
