500 Internal Server Error

Targets Web
1

I am past screaming on this one!

I have commented ALL code out except for the following and I still receive an Internal Server Error (500) when sending a request to the /api URL. Please tell me why this is happening.

Apache error log shows (I’m obviously building this for Linux)

[quote][Mon Mar 30 00:19:08.497859 2015] [cgi:error] [pid 15746] [client 10.10.0.8:33239] AH01215: Can’t use an undefined value as a symbol reference at /mnt/data/www/api/cgi-bin/stripewh/stripewh.cgi line 118.
[Mon Mar 30 00:19:08.498666 2015] [cgi:error] [pid 15746] [client 10.10.0.8:33239] End of script output before headers: stripewh.cgi[/quote]

The only code I have now in the project is

App.HandleSpecialURL

[code] Request.Status = 200
Request.Print (GetHTTPJSONStatus(200))

Return True[/code]

Shared Build Settings
Use Builds Folder: Yes
Include Function Names: Yes
Language: Default
Deployment Type: CGI
Port: Choose Automatically

Xojo: Version 2015 Release 1

2

[quote=177356:@Scott Rich]I am past screaming on this one!

I have commented ALL code out except for the following and I still receive an Internal Server Error (500) when sending a request to the /api URL. Please tell me why this is happening.

Apache error log shows (I’m obviously building this for Linux)

The only code I have now in the project is

App.HandleSpecialURL

[code] Request.Status = 200
Request.Print (GetHTTPJSONStatus(200))

Return True[/code]

Shared Build Settings
Use Builds Folder: Yes
Include Function Names: Yes
Language: Default
Deployment Type: CGI
Port: Choose Automatically

Xojo: Version 2015 Release 1[/quote]

What happens when you simply point to the cgi without /API ?

3

That particular log error usually means the app is starting but then being quickly terminated before a response is generated. This usually happens because of a couple things:

  1. Something in the App.Open event is causing an exception. This could be an invalid FolderItem or some other assumption about the environment that does not hold true and is not handled correctly via exceptions.
  2. Suexec policies are killing the app. This is usually caused by giving the cgi-bin, app folder, or app binaries/cgi files too much permissions. Suexec will enforce CGI apps having CHMOD 755 at maximum.

I have also seen this sometimes where the binary is corrupted. This is most often caused by FileZilla uploading in ASCII mode vs Binary mode because it’s “auto-detect” feature handles Xojo apps poorly. In FileZilla you can overwrite this setting with the Binary setting.

Hope that helps.

4

It’s also sometimes caused by uploading the wrong binary. It’s very easy to accidentally build a Mac binary and then upload to a Linux server because they look the same.

Some things to try:

  1. log into the terminal and just try to launch the app manually. If there is a corrupt binary, you’ll probably get errors printed in the terminal.
  2. Make sure you are uploading everything. Users sometimes forget to upload the Libs directory.
  3. Run the app with ldd. This will show you the missing dependencies if there are any: ldd yourAppName (the one without the .cgi extension)

Also, can you tell us a little about the server you are running the app on? Flavor? Version? 32 or 64 bit?

5

Line 118 as reported in the error.

 print $sock $body;

I receive the same error

[code]Sub Open(args() as String)

End Sub
[/code]

-rwxr-xr-x 1 www-data www-data 56 Mar 30 00:19 config.cfg drwxr-xr-x 3 www-data www-data 4096 Mar 30 00:18 Resources -rwxr-xr-x 1 www-data www-data 3269477 Mar 30 00:18 stripewh -rwxr-xr-x 1 www-data www-data 7023 Mar 30 00:18 stripewh.cgi drwxr-xr-x 2 www-data www-data 4096 Mar 30 00:18 stripewh Libs -rw-r--r-- 1 www-data www-data 277 Mar 30 00:18 webapp.conf

I use Macfusion (SSHFS) to copy the files. I have also used Filezilla in binary mode with the same results.

[quote]Greg: 1. log into the terminal and just try to launch the app manually. If there is a corrupt binary, you’ll probably get errors printed in the terminal.
[/quote]

root@web:/mnt/data/www/api/cgi-bin/stripewh# ./stripewh

I receive no errors.

I delete all files & directories before copying the new build

root@web:/mnt/data/www/api/cgi-bin/stripewh# ldd ./stripewh linux-gate.so.1 => (0xf7786000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf776d000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7751000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf75a2000) /lib/ld-linux.so.2 (0xf7787000)

OS: Ubuntu 14.04 LTS (64-bit)
uname -a: Linux web 3.13.0-48-generic #80-Ubuntu SMP Thu Mar 12 11:16:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Apache 2.4.7
In order to get another Xojo app to run, I had to install the ia32-libs which I really didn’t want to do since it installs so many files I’m sure I don’t need. Is there a way to force 64-bit compilation instead of 32-bit?

6

When you start the app at the command line does it start and stop or stay running until you force close?

You also need to run ldd on all of the libraries. Go into the libs folder and do a “ldd *” and see if anything is missing anything.

Xojo does not currently compile for 64bit on Linux so you must install the appropriate 32 bit libraries to proceed.

7

It appears to still be running from when I started it at the CLI.

www-data 15448     1  0 00:00 ?        00:01:04 /mnt/data/www/api/cgi-bin/stripewh/stripewh --port=22206

Not sure what I’m looking at here but…

root@web:/mnt/data/www/api/cgi-bin/stripewh/stripewh Libs# ldd * libc++.so.1: linux-gate.so.1 => (0xf76eb000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7537000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7389000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7342000) librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf7339000) libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf731c000) /lib/ld-linux.so.2 (0xf76ec000) libGZip.so: linux-gate.so.1 => (0xf77d2000) libc++.so.1 => /mnt/data/www/api/cgi-bin/stripewh/stripewh Libs/./libc++.so.1 (0xf7629000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf75d2000) libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf75b4000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7406000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf73ea000) librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf73e1000) /lib/ld-linux.so.2 (0xf77d3000) libRBCrypto.so: linux-gate.so.1 => (0xf779a000) libc++.so.1 => /mnt/data/www/api/cgi-bin/stripewh/stripewh Libs/./libc++.so.1 (0xf72a0000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7249000) libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf722b000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf707d000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7061000) librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf7058000) /lib/ld-linux.so.2 (0xf779b000) libRBInternetEncodings.so: linux-gate.so.1 => (0xf774f000) libc++.so.1 => /mnt/data/www/api/cgi-bin/stripewh/stripewh Libs/./libc++.so.1 (0xf75b9000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7562000) libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7544000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7396000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf737a000) librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf7371000) /lib/ld-linux.so.2 (0xf7750000) libRBRegEx.so: linux-gate.so.1 => (0xf7789000) libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf761a000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf75d4000) libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf75b6000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7408000) /lib/ld-linux.so.2 (0xf778a000) SSLSocket.so: linux-gate.so.1 => (0xf7749000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7519000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf74fd000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf74f7000) libc++.so.1 => /mnt/data/www/api/cgi-bin/stripewh/stripewh Libs/./libc++.so.1 (0xf7373000) libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7356000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf71a8000) /lib/ld-linux.so.2 (0xf774a000) librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf719f000) XojoConsoleFramework32.so: linux-gate.so.1 => (0xf772b000) libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xf614a000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf612e000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf6128000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf60e2000) libc++.so.1 => /mnt/data/www/api/cgi-bin/stripewh/stripewh Libs/./libc++.so.1 (0xf5f5e000) libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf5f41000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf5d93000) libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0xf5d54000) /lib/ld-linux.so.2 (0xf772c000) librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf5d4b000)

8

I have been using MacFusion to drag and drop the files from my MBP to the web server. I assumed since I was using a SSHFS connection, file operations were all done in “binary” mode. When I tried Filezilla (in Binary mode), it was after I ran the file from the CLI as Greg had suggested and received the same results. It wasn’t until my last post responding to Philip that I realized the app that was copied using MacFusion was still running.

Killing the process and using Filezilla again to transfer the build solved the issue.

** Note to all: MacFusion using SSHFS does the same thing to the build as Filezilla in text mode does.

Thanx to all who helped me resolve this issue. I can always count on you when I get thoroughly frustrated.

9

Yes updating CGI apps is not that intuitive. We posted a cheat for this scenario on our blog here: http://www.dev.1701software.com/blog/2013/09/08/upgrading-xojo-cgi-apps

10

I have the same problem now, and I can’t solve using filezilla :frowning:
Anyone have other suggestions? My web-app was working…

11

[quote=200070:@Sergio Tamborini]I have the same problem now, and I can’t solve using filezilla :frowning:
Anyone have other suggestions? My web-app was working…[/quote]

Have you quit the app ?

12

I have killed all process named myapp.cgi…