I have ran a fresh install of latest G-Wan as not daemon (e.g. ./gwan).
I request some files (also tried nonexistant files) - all OK.
I request /? (no file name, just '?') and I get a segfault and server dies.
This is repeatable every time.
The above does not happen when in daemon mode.
Anyone experienced this?
Thanks
Just tried the same thing:
http://127.0.0.1:8080/?
...and got "The requested URL was not found on this server." (as expected).
You might want to have a look at your G-WAN handler script, if any, which may not correctly handle this case.
As we updated the /include files per another question where you participated I suggest that you first download again the archive to update your include files.
The upated archive also includes the PH7 library and headers.
Related
I have a project that I am building using cygwin as an env. This weekend, I tried to do a standard git pull, one that has worked hundreds of times before, and I get this message.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
/usr/bin/ssh.exe: error while loading shared libraries: cygssp-0.dll: cannot open shared object file: No such file or directory
I'm a bit confused since this has never happened before. I googled "cygssp-0.dll" and found that it is some .dll file, specifically I looked here.
I tried the first option, and got to this step
enter "regsvr32 /u cygssp-0.dll" in the command line
and I got the message
The module "cygssp-0.dll" failed to load.
Make sure the binary is stored at the specific path or debug it to check for problems with the binary or dependent .DLL files.
The specific module could not be found.
At this point, I am thoroughly confused, and not all too keen to start reinstalling windows just yet. I've tried re installing cygwin.. does anybody have any ideas on what to do?
EDIT : I have already attempted to run setup-x86_64.exe several times, in an attempt to re-install something from the cygwin side.
Turn your antivirus off of silent mode or turn off heuristics. It's just deleting the file without telling you. libssp is getting deleted because it's a security library that does things to the call stack that antivirus programs don't like. (Specifically, it adds canaries, random values inserted into the stack that are meant to guard against some buffer overflow attacks. However, an antivirus that isn't coded to handle stack canary insertion will see it as a buffer overflow attack itself.)
Had the same issue today while trying to do push via Cygwin's git via ssh.
The solution is to reinstall or update Cygwin, as missing library will be redownloaded and put in proper place. Be sure that your antivirus software isn't removing it again, so disable everything that might delete it, and/or whitelist cygssp-0.dll location. As of today they're located under:
cygwin_root\bin\cygssp-0.dll
cygwin_root\usr\i686-pc-cygwin\sys-root\usr\bin\cygssp-0.dll
(second path only for 64 bit distribution of Cygwin)
I'm attempting to sync my local PHPStorm project from my Windows 7 PC with my Ubuntu server.
When I try any kind of connection (e.g. "Test SFTP connection"), it fails with
Invalid descendent file name "C:\nppdf32Log\debuglog.txt"
the folder mentioned doesn't exist on my Windows machine, and of course not on my Ubuntu server.
Even the most basic operation connecting to the Ubuntu server is failing because of this - Jetbrains support suggested asking here, so does anyone have a clue?
You have a file on your Ubuntu server with that C:\nppdf32Log\debuglog.txt name. YES -- it's on Ubuntu and YES -- it's actually a file name and not full path (Linux allows : and \ characters in file names).
Unfortunately such file name is invalid on Windows and library used for SFTP communications in PhpStorm does not allow to process such files in any way (yes, it's valid as full path but not as file name alone).
The solution is to connect to your SFTP using another program (e.g. FileZilla) and delete that file. After that you will be able to continue with PhpStorm built-in SFTP functionality.
P.S.
Such file is usually created by Firefox on Linux (google that file name for additional details).
https://askubuntu.com/questions/144408/what-is-the-file-c-nppdf32log-debuglog-txt
Jetbrains support suggested asking here
That's odd (and hard to believe for me) -- they should know about such issue for sure -- you are not first who is facing the same error.
In any case -- this is the ticket to watch after -- hopefully the used library (for SFTP communications) will allow handling such situations better in the future.
http://youtrack.jetbrains.com/issue/WI-2449
I met with the same problem,
but I included logging of errors (description here https://devnet.jetbrains.com/docs/DOC-1202)
and I saw that I had created a file with incorrect name
I had this same problem, but it was not due to Firefox and I wonder if the original asker might have made the same mistake I did in configuring his xdebug.
As a newbie, in setting the value for xdebug.remote_log in my php.ini (actually in separate xdebug.ini), I used the windows file path to my project on my local machine. Why? Because the value called "remote_log", so I mistakenly thought it wanted the path on my windows machine, which I thought was very strange at the time. But I am new to remote debugging, so... Oops.
Using windows path is wrong:
xdebug.remote_log="C:\Users\Buttle\PhpstormProjects\xdebug_log.txt"
And it results in:
/var/www/myproject/C:\Users\Buttle\PhpstormProjects\xdebug_log.txt
(the bolded part is the actual file name)
This is right:
xdebug.remote_log="xdebug_log.txt"
And presumably results in:
/var/www/myproject/xdebug_log.txt
(the bolded part is the actual file name)
It appears that Xdebug saves that log file inside of the folder where the requested php file came from (in my case, my project's index.php file).
I imagine that if I enter an valid linux path, I might be able to put the file somewhere else. E.g.
This might work:
xdebug.remote_log="/var/www/xdebug_log.txt"
So this solves 2 problems: 1.) why the heck doesn't xdebug log anything on its server (it does!) 2.) descendant file problem.
I am in an interesting situation where I maintain the code for a program that is used and distributed primarily by our sister company. We are ready to distribute the program to all of the 3rd party users and since it is technically our sister companies program, we want to host it on their website. (in the interest of anonimity, I'll use 'program' everywhere instead of the actual application name, and 'www.SisterCompany.com' instead of their actual URL.)
So I get everything ready to go, setup the Publish setting to check for updates at program start, the minimum required version, and I set the Insallation Folder URL and Update Location to "http://www.SisterCompany.com/apps/program/", with the actual Publishing Folder Location as "C:\LocalProjects\Program\Publish\". Everything else is pretty standard.
After publish, I confirm that everything installs and works correctly when running directly from the publish location on my C: drive. So I put everything on our FTP server, and the guy at our sister company pulls it down and places everything in the '/apps/program/' directory on their webserver.
This is where it goes bad. When I try to install it from their site, I get the - File, Program.exe.config, has a different computed hash than specified in manifest. Error. I tested it a bit, and I even get that error trying to install from any network location on our network other than my local C: drive.
After doing the initial publish in visual studio, I have changed no files (which is the answer/reason I've found by doing some searching about this error).
What could be causing this? Is it because I set the Installation Folder URL to a location that it isn't initially published too?
Let me know if any additional info is needed.
Thanks.
After bashing my head against this all weekend, I have finally found the answer. After unsigning the project and removing the hash on the offending file (an xml file), I got the program to install, but it was giving me 'Windows Side by Side' Errors. I drilled down into the App Cache were the file was, and instead of a config .xml file, it was one of the HTML files from the website the clickonce installer was hosted on. Turns out that the web server didn't seem to like serving up an .XML (or .mdb it turns out) file.
This MSDN article ended up giving me the final solution:
I had to make sure that the 'Use ".deploy" file extension' was selected so that the web server wouldn't mangle files with extensions it didn't like.
I couldn't figure out why that one file's hash would be different. Turns out it wasn't even the same file at all.
It is possible that one of the FTP transfers is happening in text mode, rather than binary?
For me the problem was that .config transformations were done after generating manifest.
To anyone else who's still having trouble, five years later:
The first problem was configuring the MIME type, which on nginx (/etc/nginx/mime.types) should look like this:
application/x-ms-manifest application
See Click Once Server and Client Configuration.
The weirder problem to me was that I was using git to handle the push to the server, i.e.
git remote add live ssh://user#mybox/path/to/publish
git commit -am "committing...";git push live master
Works great for most things, but it was probably being registered as a "change," which prevented the app from installing locally. Once I started using scp instead:
scp -r * user#mybox/path/to/dir/
It worked without a hitch.
It is unfortunate that there is not a lot of helpful information out there about this.
I am trying to install latest version of Prestashop and it fails when installing modules.
I get no error description, just that modules could not be installed and that I can try again.
I am answering my own question because maybe some day someone finds this useful.
I did some debugging to see where did the installation fail, and it was giving an error complaining about calling the install() method ona non-object variable.
I changed some php code in the modules install script, and I saw it was failing in the statnewsletter module.
I did not knew why was that, so what I did is go to the FTP and check the files of that module, and surprise, all files had 0 bytes size!
So, the porblem was that my FTP client (Filezilla) did not upload the files correctly.
I've uploaded all the prestashop files again overriding all files and then the installation worked fine.
What I've found on the web is that Filezilla can leave the file with 0 size if the server doesn't respond on the 20seconds timeout limit. And that the timeout limit can be increased in Options to avoid this happening.
Hope helps someone!
A client's Magento site had weird characters in the top of Magento Connect:
We tried installing a plugin and got the following error:
It turns out the problem was a bunch of (hidden) duplicate PHP files in lib/Mage/Connect. For example, there's Remote.php but there was also ._Remote.php. This forum post was how we found out the details.
(Deleting the duplicate files corrected the problem).
I'm wondering -- has anyone else experienced this duplicate PHP file problem in Magento before? Any idea what the cause is?
These files are mostly likely meta-data files for OS X's HFS+ file system. See this entire thread on the Apple Stack Exchange for some good starting points if you're interested in the details.
Oversimplifying things, when you create a tar archive on OS X these files are included along with the "real" file. This allows Macintosh specific meta data to survive the trip into a file format that wasn't created specifically for the Mac. If you untar the files on a Mac, the meta-data is preserved. If you untar the files on a non-Mac, the ._ files are generated in case the meta data is needed.
My guess is, at some point someone tared up those files to move them to the production server from their Mac, which brought along the the ._ files for the ride. You can avoide this in the future by running
export COPYFILE_DISABLE=true
from the terminal prior to copying the files. Details on this here.
(It's pretty bizarre that PHP would attempt to include those files instead of the correct files — did you debug this far enough to know why/what connect through it was doing?)