Thread: [Libcgi-general] some warnings

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Some annoying warnings removed from cgi.h ("blah blah, function is not
prototype"). Patch included, please apply.

  T=F5nu

	Done. The changes are in
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/libcgi

Rafael

On Mon, 2003-01-20 at 17:58, Tonu Samuel wrote:
> Some annoying warnings removed from cgi.h ("blah blah, function is not
> prototype"). Patch included, please apply.
> 
>   Tõnu

I have a cgi using libcgi.
I am new to c/cgi devel, my experience is with java servlets. I learned
during development that if it exits ungracefully it can cause "Premature
end of script headers" and an error 500, however now it does not seem to
do it in any predictable fashion and I know my program flows at least
all the way to cgi_end(). any help would be very appreciated, I am
admittedly not familiar with the platform I'm working with. My boss is
breathing down my neck.

-matt

my flow looks like this:

setuid()
cgi_init()
cgi_session_start()
cgi_process_form()
cgi_init_headers()

print a bunch of crap, register some session vars

cgi_end()

is this correct?

	Well, well.. debug cgi application, even when they are written in perl, for example,
are a bit complicate ( more than I would like ) to do. Your code may be segfaulting
because some memory allocation problem somewhere, or another function you are calling
may be sending output before cgi headers are send ( using cgi_init_headers() ).. well, 
is impossible to guess.
	Here are some ways to try debug and find the error:

*) This is the most boring and hard to do, but usually works: in you code, #define some
var to specify you want do debug:

#define DEBUG 1

Now, on the parts you guess the error may occur, put something like

#if DEBUG
cgi_init_headers();
puts("am here baby");
exit(1);
// the rest of code here
#endif
...

if you see the ouput, then change to

#if DEBUG
cgi_init_headers();
puts("am here baby");

// the rest of code here
puts("passes 'the rest of the code here'");
exit(1);
#endif

and try again.. if now the cgi breaks, so you have find here the bug is, and the could
do something to fix it.

Of course this is really suck to do, and you need to suppose *where* the bug is.

*) Go to http://log4c.sourceforge.net and the Log4C logging package for C, and then use
it to put logs into your application.. when the cgi fail, just look to the logs and see
where was the last log entry.. 

*) Try running for the command line. This one works fine and is the most simple to do,
but you should use GET instead POST ( POST forms are dificult to reproduce ). For example,
lets say you app waits to receive "name" and "email" as parameters. In the shell, do it:
( considering you are using Bash )

$ export QUERY_STRING='name=This+is+my+name&email=myemail'

Compile your cgi and then run it:

$ ./myCgi.cgi

If all worked fine, you will see the ouput, however, you may get a segfault, a library
load error or any other kind of error. Basead on the results, you could find the error.

Well, this is the methods that I use, but I agree that isn't good. If you could post here
some pieces of code you are using, this may help. Don't forget that many times the error
is with another tool or function you are using.. 

Rafael

On 22 Jan 2003 04:10:50 -0500
meb <mbe...@mi...> wrote:

> I have a cgi using libcgi.
> I am new to c/cgi devel, my experience is with java servlets. I learned
> during development that if it exits ungracefully it can cause "Premature
> end of script headers" and an error 500, however now it does not seem to
> do it in any predictable fashion and I know my program flows at least
> all the way to cgi_end(). any help would be very appreciated, I am
> admittedly not familiar with the platform I'm working with. My boss is
> breathing down my neck.
> 
> -matt

I used a similar tactic, I would put stuff like this:
fprintf(stdout,"made it this far:4");
throughout the code, which prints the messages to apache's error log.
and the code executes successfully to the cgi_end() call
On Wed, 2003-01-22 at 12:03, Rafael Steil wrote:
> 
> 	Well, well.. debug cgi application, even when they are written in perl, for example,
> are a bit complicate ( more than I would like ) to do. Your code may be segfaulting
> because some memory allocation problem somewhere, or another function you are calling
> may be sending output before cgi headers are send ( using cgi_init_headers() ).. well, 
> is impossible to guess.
> 	Here are some ways to try debug and find the error:
> 
> *) This is the most boring and hard to do, but usually works: in you code, #define some
> var to specify you want do debug:
> 
> #define DEBUG 1
> 
> Now, on the parts you guess the error may occur, put something like
> 
> #if DEBUG
> cgi_init_headers();
> puts("am here baby");
> exit(1);
> // the rest of code here
> #endif
> ...
> 
> if you see the ouput, then change to
> 
> #if DEBUG
> cgi_init_headers();
> puts("am here baby");
> 
> // the rest of code here
> puts("passes 'the rest of the code here'");
> exit(1);
> #endif
> 
> and try again.. if now the cgi breaks, so you have find here the bug is, and the could
> do something to fix it.
> 
> Of course this is really suck to do, and you need to suppose *where* the bug is.
> 
> 
> *) Go to http://log4c.sourceforge.net and the Log4C logging package for C, and then use
> it to put logs into your application.. when the cgi fail, just look to the logs and see
> where was the last log entry.. 
> 
> *) Try running for the command line. This one works fine and is the most simple to do,
> but you should use GET instead POST ( POST forms are dificult to reproduce ). For example,
> lets say you app waits to receive "name" and "email" as parameters. In the shell, do it:
> ( considering you are using Bash )
> 
> $ export QUERY_STRING='name=This+is+my+name&email=myemail'
> 
> Compile your cgi and then run it:
> 
> $ ./myCgi.cgi
> 
> If all worked fine, you will see the ouput, however, you may get a segfault, a library
> load error or any other kind of error. Basead on the results, you could find the error.
> 
> Well, this is the methods that I use, but I agree that isn't good. If you could post here
> some pieces of code you are using, this may help. Don't forget that many times the error
> is with another tool or function you are using.. 
> 
> Rafael
> 
> On 22 Jan 2003 04:10:50 -0500
> meb <mbe...@mi...> wrote:
> 
> > I have a cgi using libcgi.
> > I am new to c/cgi devel, my experience is with java servlets. I learned
> > during development that if it exits ungracefully it can cause "Premature
> > end of script headers" and an error 500, however now it does not seem to
> > do it in any predictable fashion and I know my program flows at least
> > all the way to cgi_end(). any help would be very appreciated, I am
> > admittedly not familiar with the platform I'm working with. My boss is
> > breathing down my neck.
> > 
> > -matt
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> Libcgi-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libcgi-general

	So, the script goes to the end, and then you get and internall
error, but *aparentely* all is fine.. that's it? Its complitaced to
say exactly what could be causing this problem.. have you tried to 
remove cgi_end() function call? Sometime ago, when I was developing some
parts, cgi_end() did invalid pointer operations, which caused some
memory faults.. try it, remove cgi_end() and tell us the result. 

Note, all is to work fine, but.... Another question: what version of
libcgi are you using, and what is the OS ?

Rafael

On Wed, 2003-01-22 at 15:58, meb wrote:
> I used a similar tactic, I would put stuff like this:
> fprintf(stdout,"made it this far:4");
> throughout the code, which prints the messages to apache's error log.
> and the code executes successfully to the cgi_end() call
> On Wed, 2003-01-22 at 12:03, Rafael Steil wrote:

uh oh.
commenting out cgi_end() fixed it.
I can't get the error 400 anymore.

how bad is it to leave that out of my cgi.
is there any information you would like to locate the problem?
On Wed, 2003-01-22 at 14:14, Rafael Steil wrote:

thanks alot,
I am very satisfied with your library anyway.
> 	So, the script goes to the end, and then you get and internall
> error, but *aparentely* all is fine.. that's it? Its complitaced to
> say exactly what could be causing this problem.. have you tried to 
> remove cgi_end() function call? Sometime ago, when I was developing some
> parts, cgi_end() did invalid pointer operations, which caused some
> memory faults.. try it, remove cgi_end() and tell us the result. 
> 
> Note, all is to work fine, but.... Another question: what version of
> libcgi are you using, and what is the OS ?
> 
> Rafael
> 
> On Wed, 2003-01-22 at 15:58, meb wrote:
> > I used a similar tactic, I would put stuff like this:
> > fprintf(stdout,"made it this far:4");
> > throughout the code, which prints the messages to apache's error log.
> > and the code executes successfully to the cgi_end() call
> > On Wed, 2003-01-22 at 12:03, Rafael Steil wrote:
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> Libcgi-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libcgi-general

	Ugh.. cgi_end() sucks.. well, you can give it away, the function
intention is just to do some memory cleanups and other things relacted.
You could help informing which version of LibCGI are you using and the
OS. 

Rafael

On Wed, 2003-01-22 at 16:29, meb wrote:
> uh oh.
> commenting out cgi_end() fixed it.
> I can't get the error 400 anymore.
> 
> how bad is it to leave that out of my cgi.
> is there any information you would like to locate the problem?
> On Wed, 2003-01-22 at 14:14, Rafael Steil wrote:
> 
> thanks alot,
> I am very satisfied with your library anyway.

0.8.1 is the libcgi version and I'm using rh7.3 with apache 1.3.23.
I'm also linking against libmysql 10.0.0 and libmaildir from maildrop
1.5.1

"well, you can give it away"
does this mean that omitting cgi_end() is safe? it would seem to me that
with a cgi which is a short lived process that memory cleanups aren't
that import because as soon as it returns the os will clean it up?
unlike java servlets which never return.
On Wed, 2003-01-22 at 14:46, Rafael Steil wrote:
> 	Ugh.. cgi_end() sucks.. well, you can give it away, the function
> intention is just to do some memory cleanups and other things relacted.
> You could help informing which version of LibCGI are you using and the
> OS. 
> 
> Rafael
> 
> On Wed, 2003-01-22 at 16:29, meb wrote:
> > uh oh.
> > commenting out cgi_end() fixed it.
> > I can't get the error 400 anymore.
> > 
> > how bad is it to leave that out of my cgi.
> > is there any information you would like to locate the problem?
> > On Wed, 2003-01-22 at 14:14, Rafael Steil wrote:
> > 
> > thanks alot,
> > I am very satisfied with your library anyway.
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> Libcgi-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libcgi-general

	I need to revise cgi_end().. for now, the only thing it does is free 
cookies and session vars from memory.. not a big issue. In future releases, 
cgi_end() intention is to make a complete memory cleanup, but to do that we need
memory management functions before. So, comment the call to this funciton and
be happy :)

	Java Servlets stays in memory and the GC does the hard job of memory
management. You can think cgi_end() as being destroy() method from HttpServlet.

Rafael

On 22 Jan 2003 17:34:22 -0500
meb <mbe...@mi...> wrote:

> 0.8.1 is the libcgi version and I'm using rh7.3 with apache 1.3.23.
> I'm also linking against libmysql 10.0.0 and libmaildir from maildrop
> 1.5.1
> 
> "well, you can give it away"
> does this mean that omitting cgi_end() is safe? it would seem to me that
> with a cgi which is a short lived process that memory cleanups aren't
> that import because as soon as it returns the os will clean it up?
> unlike java servlets which never return.
> On Wed, 2003-01-22 at 14:46, Rafael Steil wrote:

On Thu, 2003-01-23 at 13:46, Rafael Steil wrote:
>=20
> 	I need to revise cgi_end().. for now, the only thing it does is free=20
> cookies and session vars from memory.. not a big issue. In future release=
s,=20
> cgi_end() intention is to make a complete memory cleanup, but to do that =
we need
> memory management functions before. So, comment the call to this funciton=
 and
> be happy :)

I have it!

I do not remember what exact version is in CVS right now but I use it
in-house for some time already. SourceForge project "dbug" is it.

Today I am very sleepy but I can revise it some other day.

  T=F5nu

	Oh, yeah, right... You have did it.. my fault, I thought that this bug
was fixed in 0.8.1 version, but no.. the CVS version is the correct. Sorry =
Tonu.

The bug is in list_free() function ( list.c file ). The CVS version is here:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/libcgi/libcgi-devel/src/list=
.c?rev=3D1.2&content-type=3Dtext/vnd.viewcvs-markup

Rafael

On 23 Jan 2003 14:59:04 +0200
Tonu Samuel <to...@pl...> wrote:

> On Thu, 2003-01-23 at 13:46, Rafael Steil wrote:
> >=20
> > 	I need to revise cgi_end().. for now, the only thing it does is free=20
> > cookies and session vars from memory.. not a big issue. In future relea=
ses,=20
> > cgi_end() intention is to make a complete memory cleanup, but to do tha=
t we need
> > memory management functions before. So, comment the call to this funcit=
on and
> > be happy :)
>=20
> I have it!
>=20
> I do not remember what exact version is in CVS right now but I use it
> in-house for some time already. SourceForge project "dbug" is it.
>=20
> Today I am very sleepy but I can revise it some other day.
>=20
>   T=F5nu