Thread: PL compile warning messages
With the new PL code in pl/tcl I am getting a bunch of warnings like the following: pltcl.c:443: warning: variable `prodesc' might be clobbered by `longjmp' or `vfork' I have never seen this before in any of my programming. What do they mean? Is anyone else seeing these? Does it matter? Cheers, Brook
> > With the new PL code in pl/tcl I am getting a bunch of warnings like > the following: > > pltcl.c:443: warning: variable `prodesc' might be clobbered by `longjmp' or `vfork' > > I have never seen this before in any of my programming. What do they > mean? Is anyone else seeing these? Does it matter? > > Cheers, > Brook > > I get them too and don't know exactly what they mean. I think gcc is just telling that after returning to the setjmp location via longjmp the variable might not contain what there was before (the longjmp mechanism only restores the stack pointers, not the variable contents on the stack). But the longjmp's are there only to clean up the Tcl's interpreter nesting and allocations in the case of an elog(ERROR) before really jumping back into the postgres main loop. Tcl doesn't allocate via palloc, so there would be memory allocations never free'd otherwise. The mentioned variables aren't accessed after the longjumping session began (it's really a longjmp party if Tcl triggers use in turn Tcl functions where the queries invoke other functions/triggers and so on :-). Since PL/Tcl is designed to be used as trigger language, raising errors with elog would be a normal operation from inside of PL/Tcl. Nothing I tested so far is really broken. I assume it doesn't really matter. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) #
> I get them too and don't know exactly what they mean. I think > gcc is just telling that after returning to the setjmp > location via longjmp the variable might not contain what > there was before (the longjmp mechanism only restores the > stack pointers, not the variable contents on the stack). > > But the longjmp's are there only to clean up the Tcl's > interpreter nesting and allocations in the case of an > elog(ERROR) before really jumping back into the postgres main > loop. Tcl doesn't allocate via palloc, so there would be > memory allocations never free'd otherwise. The mentioned > variables aren't accessed after the longjumping session began > (it's really a longjmp party if Tcl triggers use in turn Tcl > functions where the queries invoke other functions/triggers > and so on :-). See postgres.c. We used to have that warning in postgres.c, but someone changed something to fix it. I can't see what was changed, now that I am looking at it. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce wrote: > > > I get them too and don't know exactly what they mean. I think > > gcc is just telling that after returning to the setjmp > > location via longjmp the variable might not contain what > > there was before (the longjmp mechanism only restores the > > stack pointers, not the variable contents on the stack). > > > > But the longjmp's are there only to clean up the Tcl's > > interpreter nesting and allocations in the case of an > > elog(ERROR) before really jumping back into the postgres main > > loop. Tcl doesn't allocate via palloc, so there would be > > memory allocations never free'd otherwise. The mentioned > > variables aren't accessed after the longjumping session began > > (it's really a longjmp party if Tcl triggers use in turn Tcl > > functions where the queries invoke other functions/triggers > > and so on :-). > > See postgres.c. We used to have that warning in postgres.c, but someone > changed something to fix it. I can't see what was changed, now that I > am looking at it. I took a lood at it and didn't saw the changes either. Then I played around with the code. In some cases only a strange workaround could prevent that warning. Creating another variable of the same type and somewhere in the function doing var2 = var1; and then using var2 instead (doesn't do anything useful and makes the code more obscure). From the gcc manpage: -W Print extra warning messages for these events: · A nonvolatile automatic variable might be changed by a call to longjmp. These warnings are possible only in optimizing compilation. The compiler sees only the calls to setjmp. It cannot know where longjmp will be called; in fact, a signal handler could call it at any point in the code. As a result, you may get a warning even when there is in fact no problem because longjmp cannot in fact be called at the place which would cause a problem. In fact I think it's legal to ignore these warnings because there is in fact no place which would cause a problem. And in fact I love this snippet of the manpage :-) Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) #