Composer: Symfony Signal 5 Schwerwiegender Fehler

Könnte ich auch die Ausnahmemeldung sehen, nicht nur die Ablaufverfolgung?

[SymfonyComponentProcessExceptionRuntimeException]
Der Vorgang wurde mit Signal "5" signalisiert.

Gibt es darüber irgendwelche Neuigkeiten? Ich habe auf 1.0.0-alpha7 zurückgesetzt und es funktioniert immer noch nicht. Ich kann nicht einmal eine Probeinstallation oder ein Update durchführen

@robertdown : Können Sie auch einige Details zu Ihrem Betriebssystem teilen? Und hast du eine frühere Version verwendet, die funktioniert hat? Wenn ja, welches?

OSX, 10.7.5. Ich habe eine frühere Version verwendet, die funktioniert hat, bin mir aber bei der Version nicht sicher.

Ich habe auch einen Produktions-Linux-Server, auf dem Composer ausgeführt wird (derzeit erfolgreich) - aber es scheint, dass ein Kollege derzeit Wartungsarbeiten auf dem Server durchführt, sodass ich die Composer-Version nicht erhalten kann - ich werde es so schnell wie möglich posten zurück in.

Haben wir uns diesbezüglich bewegt? Es lähmt meinen Workflow. Ich habe alle Überreste von Composer entfernt, einschließlich .composer, und die neueste Kopie von http://getcomposer.org/download/ mit . heruntergeladen
curl -sS https://getcomposer.org/installer | php
habe die composer.phar in mein Projekt verschoben, php composer.php update und ich habe immer noch den Fehler.

@romainneutron eine idee? Signal 5 ist SIGTRAP, aber ich habe keine Ahnung, woher das kommen könnte.

@robertdown könnten Sie es erneut mit -vvv ausführen und die letzte CMD-Zeile über der Ausnahme einfügen? Nur um genau zu sehen, welcher Befehl so getötet wird.

Hallo alle,

es scheint, dass SIGTRAP für Debugging-/Breakpoint-/Trace-Zwecke verwendet wird. Welche PHP-Version verwendest du? Verwenden Sie einen Debugger oder Profiler?

PHP 5.4.16. Ich habe einen Debugger installiert, aber ich hatte ihn immer installiert und hat nie Probleme mit Composer verursacht.

() at phar:///usr/local/zend/apache2/htdocs/mc-deployment/composer.phar/vendor/symfony/process/Symfony/Component/Process/Process.php:428

@robertdown Das ist Teil des PHP-Stack-Trace, der letzte Befehl ist die letzte Zeile in der Ausgabe, die mit Executing command beginnt.

Executing command konnte nicht gefunden werden

Hallo Robert,

Ich frage Sie, ob Sie einen Debugger haben, da SIGTRAP im Allgemeinen von Debuggern verwendet wird. Wenn Sie der Meinung sind, dass Ihr Debugger nichts mit Ihrem Problem zu tun hat, lassen Sie uns dies ignorieren.

Es wäre schön, zusammenzuarbeiten und einige Tests ohne diesen Debugger durchzuführen. Dieses Problem tritt nicht so häufig auf, ich glaube, es liegt nicht am Composer, sondern an Ihrer Konfiguration. Ich kann mich irren, lassen Sie uns in der Zwischenzeit zusammenarbeiten, oder wir lösen dieses Problem möglicherweise nicht.

Ok, ich habe den Debugger deaktiviert und meinen Server neu gestartet und ich bekomme immer noch
der gleiche Fehler. Ich habe mir den Kopf zerbrochen, um zu sehen, ob ich mich an etwas erinnern kann
Ich habe mich vielleicht in letzter Zeit verändert, aber mir fällt nichts ein.

Grüße,
Robert Down

Von: Romain Neutron [email protected]
Antwort-An: Komponist/Komponist
hub.com>
Datum: Freitag, 16. August 2013 18:24
An: Komponist/Komponist [email protected]
Cc: "Robert Down, Jr" [email protected]
Betreff: Re: [Komponist] Symfony Signal 5 Fatal Error (#2146)

Hallo Robert,

Ich frage Sie, ob Sie einen Debugger haben, da SIGTRAP im Allgemeinen von verwendet wird
Debugger. Wenn Sie der Meinung sind, dass Ihr Debugger nichts mit Ihrem Problem zu tun hat, nun,
Lass uns das ignorieren.

Es wäre schön, zusammenzuarbeiten und einige Tests ohne dies zu versuchen
Debugger. Dieses Problem ist nicht so häufig, ich glaube, es geht nicht um den Komponisten
aber über deine Konfiguration. Ich kann mich irren, lass uns in der Zwischenzeit kooperieren oder wir
könnte dieses Problem nicht lösen.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/composer/composer/issues/2146#issuecomment -22797852 .

@Seldaek Gibt es eine einfache Möglichkeit, eine ältere Version von Composer herunterzuladen, die Symfony / Process 2.2 verwendet und die mit der aktuellen Packagist-API zum Testen funktionieren würde?

Ich habe gerade versucht, das Composer-Repository zu klonen und 3ffad59719bd94987813ea1872001619200c24a0 zu erstellen (diese Version stammte von einem anderen Server, den ich verwalte, auf dem Composer ordnungsgemäß funktioniert).

Um Composer aus dem Quellcode zu installieren, müssen Sie natürlich Composer.phar verwenden...... keine Würfel

Um Composer aus der Quelle zu installieren, müssen Sie natürlich verwenden
Komponist.Phar......keine Würfel

Sie können ein Phar installieren/erstellen (bin/compile ausführen) auf einem anderen Computer und
Übertragen Sie dann das Phar zum Testen auf den defekten Server.

Konnte nicht finden |Befehl wird ausgeführt|

Entschuldigung für den fehlenden Befehl in der Ausgabe, das war mein Fehler. wenn du
Versuchen Sie es mit dem neuesten Phar, der jetzt angezeigt werden sollte.

reading ./composer.json
Executing command (CWD): git describe --exact-match --tags
Reading ./composer.json
Executing command (CWD): git describe --exact-match --tags

Sidebar: Warum wird die Datei zweimal gelesen?

Welchen Befehl führst du genau aus? Und was ist die volle Leistung? ich
nicht zweimal lesen, aber es ist möglich, dass es zweimal gelesen wird
Aus verschiedenen Gründen.

OK, also zunächst scheint es, dass es beim ersten Mal gut läuft und nicht das
zweitens, obwohl alles gleich ist. Das ist seltsam.

Die zweite seltsame Sache ist, dass es zweimal ausgeführt und zweimal geladen wird.

Kannst du deine composer.json teilen? Denn selbst wenn ich den gleichen Befehl ausführe
So wie du verstehe ich diese doppelte Ladung nicht.

Als Randnotiz. Ich nehme an, wenn Sie den Befehl selbst im ausführen
gleiches Verzeichnis wie du Composer ausgeführt hast, geht es gut?

git describe --exact-match --tags

Entschuldigung für den letzten Kommentar, ich habe ihn aus meiner E-Mail gesendet und ich denke, github analysiert keine E-Mails über GFM

Meine Composer-Datei wird Ihnen nicht viel nützen, wir haben Closed-Source-Repos, aus denen wir ziehen.

Aber das ist egal…. Dieser Teil ist viel interessanter

rdown [21:27] mc-deployment $ git describe --exact-match --tags
fatal: no tag exactly matches 'b11cb924e52b488ff68f53b37b30a73d38dbdae8'

ABER! Wenn ich ein Tag auschecke (in diesem Fall 1.3.1), erhalte ich Folgendes

rdown [21:29] mc-deployment $ git describe --exact-match --tags
1.3.1

Und es schlägt immer noch fehl, unten ist die Spur, wenn ich auf Tag 1.3.1 bin

 [Symfony\Component\Process\Exception\RuntimeException]
  The process has been signaled with signal 5.

Exception trace:
 () at
phar:///usr/local/zend/apache2/htdocs/mc-deployment/composer.phar/vendor/sym fony/process/Symfony/Component/Process/Process.php:428
 Symfony\Component\Process\Process->wait() at
phar:///usr/local/zend/apache2/htdocs/mc-deployment/composer.phar/vendor/sym
fony/process/Symfony/Component/Process/Process.php:204
 Symfony\Component\Process\Process->run() at
phar:///usr/local/zend/apache2/htdocs/mc-deployment/composer.phar/src/Compos
er/Util/ProcessExecutor.php:61
 Composer\Util\ProcessExecutor->execute() at
phar:///usr/local/zend/apache2/htdocs/mc-deployment/composer.phar/src/Compos
er/Package/Loader/RootPackageLoader.php:192
 Composer\Package\Loader\RootPackageLoader->guessGitVersion() at
phar:///usr/local/zend/apache2/htdocs/mc-deployment/composer.phar/src/Compos
er/Package/Loader/RootPackageLoader.php:177
 Composer\Package\Loader\RootPackageLoader->guessVersion() at
phar:///usr/local/zend/apache2/htdocs/mc-deployment/composer.phar/src/Compos
er/Package/Loader/RootPackageLoader.php:57
 Composer\Package\Loader\RootPackageLoader->load() at
phar:///usr/local/zend/apache2/htdocs/mc-deployment/composer.phar/src/Compos
er/Factory.php:237
 Composer\Factory->createComposer() at
phar:///usr/local/zend/apache2/htdocs/mc-deployment/composer.phar/src/Compos
er/Factory.php:408
 Composer\Factory::create() at
phar:///usr/local/zend/apache2/htdocs/mc-deployment/composer.phar/src/Compos
er/Console/Application.php:175
 Composer\Console\Application->getComposer() at
phar:///usr/local/zend/apache2/htdocs/mc-deployment/composer.phar/src/Compos
er/Command/Command.php:50
 Composer\Command\Command->getComposer() at
phar:///usr/local/zend/apache2/htdocs/mc-deployment/composer.phar/src/Compos
er/Command/UpdateCommand.php:63
 Composer\Command\UpdateCommand->execute() at
phar:///usr/local/zend/apache2/htdocs/mc-deployment/composer.phar/vendor/sym
fony/console/Symfony/Component/Console/Command/Command.php:244
 Symfony\Component\Console\Command\Command->run() at
phar:///usr/local/zend/apache2/htdocs/mc-deployment/composer.phar/vendor/sym
fony/console/Symfony/Component/Console/Application.php:897
 Symfony\Component\Console\Application->doRunCommand() at
phar:///usr/local/zend/apache2/htdocs/mc-deployment/composer.phar/vendor/sym
fony/console/Symfony/Component/Console/Application.php:191
 Symfony\Component\Console\Application->doRun() at
phar:///usr/local/zend/apache2/htdocs/mc-deployment/composer.phar/src/Compos
er/Console/Application.php:117
 Composer\Console\Application->doRun() at
phar:///usr/local/zend/apache2/htdocs/mc-deployment/composer.phar/vendor/sym
fony/console/Symfony/Component/Console/Application.php:121
 Symfony\Component\Console\Application->run() at
phar:///usr/local/zend/apache2/htdocs/mc-deployment/composer.phar/src/Compos
er/Console/Application.php:83
 Composer\Console\Application->run() at
phar:///usr/local/zend/apache2/htdocs/mc-deployment/composer.phar/bin/compos
er:43
 require() at /usr/local/zend/apache2/htdocs/mc-deployment/composer.phar:15

Ja, das ist das erwartete Verhalten (das fatale). Es ist gefangen und wenn die
Der Prozess schlägt fehl, wir lesen die Ausgabe einfach nicht.

Könntest du mir eine Kopie deines composer.json mit geschwärzten URLs geben
obwohl es immer noch nützlich sein könnte herauszufinden, warum es das gibt
doppeltes Laden von Composer.json. Es muss nicht installierbar sein für
mir, da dies sehr früh im Bootstrap-Prozess passiert, wie es scheint.
Alternativ können Sie es auch per E-Mail an j senden. [email protected] wenn es dir nicht gefällt
es öffentlich zu machen.

Ich verstehe, warum es fehlschlagen würde, wenn git describe fehlschlägt, aber als ich zum Tag wechselte, schlug es immer noch fehl, obwohl git describe übergeben wurde, darunter eine geschwärzte Datei composer.json

{
    "license": "proprietary",
    "keywords" : [],
    "require" : {
        "redacted" : "1.3",
        "redacted" : "1.3.5"
    },
    "autoload" : {
        "psr-0" : {
            "Application\\" : "src/"
        }
    },
    "repositories" : [{
            "type" : "vcs",
            "url" : "[email protected]:redacted/redacted.git"
        }, {
            "type" : "vcs",
            "url" : "[email protected]:redacted/redacted.git"
        }
    ]
}

Vielen Dank. Aber kein Glück :/ Das ist wirklich rätselhaft.

Könnte es ein Problem mit einem der Repos sein, aus denen wir ziehen?

Können Sie den Fehler reproduzieren?

Grüße,
Robert Down

Von: Jordi Boggiano [email protected]
Antwort-An: Komponist/Komponist
hub.com>
Datum: Freitag, 16. August 2013 21:54
An: Komponist/Komponist [email protected]
Cc: "Robert Down, Jr" [email protected]
Betreff: Re: [Komponist] Symfony Signal 5 Fatal Error (#2146)

Vielen Dank. Aber kein Glück :/ Das ist wirklich rätselhaft.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/composer/composer/issues/2146#issuecomment -22803565 .

Nein, ich kann es nicht reproduzieren, und ich bezweifle wirklich, dass es mit Ihren Repos zusammenhängt.
Sie können dies jedoch leicht überprüfen, indem Sie die benutzerdefinierten Repos entfernen und sehen, ob
es lädt immer noch zweimal und schlägt fehl.

Haben Sie einen Einblick in den Signal 5-Fehler?

Ich habe meine Composer.json-Datei auf ein Minimum reduziert – alles, was es erfordert, ist
monolog, nur ein zufälliges Paket, das ich gerade von Packagist gezogen habe, immer noch nein
Glück.

Grüße,
Robert Down

Von: Jordi Boggiano [email protected]
Antwort-An: Komponist/Komponist
hub.com>
Datum: Freitag, 16. August 2013 22:04
An: Komponist/Komponist [email protected]
Cc: "Robert Down, Jr" [email protected]
Betreff: Re: [Komponist] Symfony Signal 5 Fatal Error (#2146)

Nein, ich kann es nicht reproduzieren, und ich bezweifle wirklich, dass es mit Ihren Repos zusammenhängt.
Sie können dies jedoch leicht überprüfen, indem Sie die benutzerdefinierten Repos entfernen und sehen, ob
es lädt immer noch zweimal und schlägt fehl.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/composer/composer/issues/2146#issuecomment -22803730 .

Nein sorry, aber ich habe wirklich keine Ahnung woran das liegt.

Debuggen mit dbg sollte dies aufdecken. Falls der Reporter also mehr erfahren möchte, warum nicht innerhalb einer dbg-Sitzung und bei diesem Signal anhalten?

Hallo,

Wenn ich das richtig verstehe, schlägt das git describe --exact-match --tags fehl, weil ein SIGTRAP Signal ?
Welches Git wird verwendet ( which git Ausgabe) ? Ist es der von Xcode bereitgestellte? Ist das eine Sonderanfertigung?

Ich glaube, das ist noch so. Ich führe einen benutzerdefinierten Build von Git aus ( usr/bin/git Version 1.8.3.4)

Checking platform settings: OK
Checking http connectivity: Downloading https://packagist.org/packages.json
OK
Reading ./composer.json
Executing command (CWD): git describe --exact-match --tags
Reading ./composer.json
Executing command (CWD): git describe --exact-match --tags



  [Symfony\Component\Process\Exception\RuntimeException]
  The process has been signaled with signal "5".



Exception trace:
 () at phar:///usr/local/bin/composer/vendor/symfony/process/Symfony/Component/Process/Process.php:428
 Symfony\Component\Process\Process->wait() at phar:///usr/local/bin/composer/vendor/symfony/process/Symfony/Component/Process/Process.php:204
 Symfony\Component\Process\Process->run() at phar:///usr/local/bin/composer/src/Composer/Util/ProcessExecutor.php:61
 Composer\Util\ProcessExecutor->execute() at phar:///usr/local/bin/composer/src/Composer/Package/Loader/RootPackageLoader.php:192
 Composer\Package\Loader\RootPackageLoader->guessGitVersion() at phar:///usr/local/bin/composer/src/Composer/Package/Loader/RootPackageLoader.php:177
 Composer\Package\Loader\RootPackageLoader->guessVersion() at phar:///usr/local/bin/composer/src/Composer/Package/Loader/RootPackageLoader.php:57
 Composer\Package\Loader\RootPackageLoader->load() at phar:///usr/local/bin/composer/src/Composer/Factory.php:228
 Composer\Factory->createComposer() at phar:///usr/local/bin/composer/src/Composer/Factory.php:399
 Composer\Factory::create() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:175
 Composer\Console\Application->getComposer() at phar:///usr/local/bin/composer/src/Composer/Command/Command.php:50
 Composer\Command\Command->getComposer() at phar:///usr/local/bin/composer/src/Composer/Command/DiagnoseCommand.php:65
 Composer\Command\DiagnoseCommand->execute() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Command/Command.php:244
 Symfony\Component\Console\Command\Command->run() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:897
 Symfony\Component\Console\Application->doRunCommand() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:191
 Symfony\Component\Console\Application->doRun() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:117
 Composer\Console\Application->doRun() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:121
 Symfony\Component\Console\Application->run() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:83
 Composer\Console\Application->run() at phar:///usr/local/bin/composer/bin/composer:43
 require() at /usr/local/bin/composer:15


diagnose

Können Sie versuchen, denselben Befehl mit XCode-Git auszuführen, das mit Befehlszeilentools bereitgestellt wird (befindet sich in /usr/bin/git ) ?

/usr/bin/git verweist auf meine benutzerdefinierte Git-Installation. Ich glaube wirklich nicht, dass dies ein Git-Problem ist, aber ich bin jetzt wirklich verwirrt, ich habe gerade eine vollständige Neuinstallation von Apache und PHP durchgeführt und immer noch nichts.

Es scheint, dass es der git-Befehl ist, der von einem SIGTRAP getötet wird. Forumsbenutzer berichteten von einigen unerwarteten SIGTRAP-Signalen in Programmen, die mit fehlerhaften gcc-Versionen kompiliert wurden.

Ok, ich habe die Befehlszeilentools von Xcode neu installiert, die mich zu git version 1.7.12.4 (Apple Git-37) und dies löste das Problem. Anscheinend habe ich git mit einer fehlerhaften Version von gcc gebaut. Haben wir Grund zu der Annahme, dass Composer nicht mit git 1.8.3.4 arbeitet?

Nicht, dass ich wüsste... aber es ist nicht so, dass ich irgendwelche Zahlen dazu hätte.

Gut, dass wir das gelöst haben!

Ich verwende die Git-Version 1.8.3.1, die über Homebrew und gcc installiert ist i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (basierend auf Apple Inc. Build 5658) (LLVM-Build 2336.11.00) und ich tue es nicht auf das Problem stoßen

gerade auf 1.8.3.4 gestoßen, immer noch kein Problem

Schließen, da wir hier anscheinend nicht helfen können. Hoffentlich wurde es von Ihrer Seite gelöst.

Ich habe das gleiche Problem mit 10.9.1 nach der Selbstaktualisierung des Komponisten. Ich habe versucht, die xcode-Befehlszeilentools neu zu installieren und git aus dem offiziellen Paket zu installieren. Bekomme immer noch den gleichen Fehler.

Ich hatte das gleiche Problem, das von svn, Version 1.7.10 (r1485443) verursacht wurde. Ich habe svn in /usr/bin in /usr/bin/svn.orig umbenannt und meine Probleme wurden behoben.

Lesen von ./composer.json
Ausführen des Befehls (CWD): git describe --exact-match --tags
Ausführen des Befehls (CWD): git branch --no-color --no-abbrev -v
Ausführendes Kommando (CWD): hg branch
Ausführen des Befehls (CWD): svn info --xml
Lesen von ./composer.json
Ausführen des Befehls (CWD): git describe --exact-match --tags
Ausführen des Befehls (CWD): git branch --no-color --no-abbrev -v
Ausführendes Kommando (CWD): hg branch
Ausführen des Befehls (CWD): svn info --xml

[SymfonyComponentProcessExceptionRuntimeException]
Der Vorgang wurde mit Signal "5" signalisiert.

Ausnahme-Trace:
() unter phar:///Users/mgoolie/composer.phar/vendor/symfony/process/Symfony/Component/Process/Process.php:330
SymfonyComponentProcessProcess->wait() at phar:///Users/mgoolie/composer.phar/vendor/symfony/process/Symfony/Component/Process/Process.php:200
SymfonyComponentProcessProcess->run() at phar:///Users/mgoolie/composer.phar/src/Composer/Util/ProcessExecutor.php:61
ComposerUtilProcessExecutor->execute() at phar:///Users/mgoolie/composer.phar/src/Composer/Package/Loader/RootPackageLoader.php:307
ComposerPackageLoaderRootPackageLoader->guessSvnVersion() at phar:///Users/mgoolie/composer.phar/src/Composer/Package/Loader/RootPackageLoader.php:187
ComposerPackageLoaderRootPackageLoader->guessVersion() at phar:///Users/mgoolie/composer.phar/src/Composer/Package/Loader/RootPackageLoader.php:57
ComposerPackageLoaderRootPackageLoader->load() at phar:///Users/mgoolie/composer.phar/src/Composer/Factory.php:239
ComposerFactory->createComposer() at phar:///Users/mgoolie/composer.phar/src/Composer/Factory.php:448
ComposerFactory::create() at phar:///Users/mgoolie/composer.phar/src/Composer/Console/Application.php:176
ComposerConsoleApplication->getComposer() at phar:///Users/mgoolie/composer.phar/src/Composer/Command/Command.php:51
ComposerCommandCommand->getComposer() at phar:///Users/mgoolie/composer.phar/src/Composer/Command/DumpAutoloadCommand.php:44
ComposerCommandDumpAutoloadCommand->execute() at phar:///Users/mgoolie/composer.phar/vendor/symfony/console/Symfony/Component/Console/Command/Command.php:241
SymfonyComponentConsoleCommandCommand->run() at phar:///Users/mgoolie/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php:892
SymfonyComponentConsoleApplication->doRunCommand() at phar:///Users/mgoolie/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php:191
SymfonyComponentConsoleApplication->doRun() at phar:///Users/mgoolie/composer.phar/src/Composer/Console/Application.php:117
ComposerConsoleApplication->doRun() at phar:///Users/mgoolie/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php:121
SymfonyComponentConsoleApplication->run() at phar:///Users/mgoolie/composer.phar/src/Composer/Console/Application.php:83
ComposerConsoleApplication->run() at phar:///Users/mgoolie/composer.phar/bin/composer :43
require() unter /Users/mgoolie/composer. phar:15

dump-autoload [-o|--optimize]

"Dieses Problem sollte sich nur zeigen, wenn Sie ein PHP-Skript haben, das system("svn") aufruft.
Es passiert, weil OS X local svn die Installation der lokalen libsasl erfordert, aber Zends PHP verwendet seinen eigenen libsasl-Build. svn und PHP teilen sich jedoch nicht den gleichen Adressraum, sondern nur die gleiche Umgebung, also müssen wir nur jedem die Umgebung geben, die er möchte."

(von http://forums.zend.com/viewtopic.php?f=8&t=107973#p202868)

Was mir im Grunde geholfen hat, war, diese Zeile hinzuzufügen:

putenv("DYLD_LIBRARY_PATH=''");

oben in der Datei Process.php des Komponisten.

Danke schön!

Ich erhalte immer noch diesen Fehler und weiß nicht, wie ich diese Variable in die Prozessdatei einfügen soll.
Ich habe versucht, es als Umgebungsvariable festzulegen, und es funktioniert immer noch nicht.
Irgendeine Idee?

auf einem Mac, mit PHP von MAMP und dem neuesten Build von Composer.
Ich bekomme den Fehler jedes Mal, wenn ich ein Update oder eine Installation mache.

Mac OS X 10.9.2
welches php /Applications/MAMP/bin/php/php5.4.19/bin/php
meine .zshrc-Datei
export PATH="/Applications/MAMP/bin/php/php5.4.19/bin:$PATH"
Alias ​​Composer="php /Volumes/Boot/usr/local/bin/composer.phar"

Danke, das hat bei mir funktioniert:
$brew install svn
$brew link --subversion überschreiben

das hat bei mir auch funktioniert!:
$brew install svn
$brew link --subversion überschreiben

Sie sollten Ihre Mac-Version aktualisieren, Maverick werden und dann Composer installieren und aktualisieren.

Weitere Informationen für alle anderen, die immer noch auf Fehler wie diesen stoßen.

Bevor ich auf dieses Problem mit Composer und SymfonyComponentProcess gestoßen bin, bin ich darauf gestoßen, als ich an etwas anderem gearbeitet habe, das die grundlegende Verwendung von exec() beinhaltet.

exec("git log",$ausgabe); print_r($Ausgabe);

Dies gab nichts zurück, während andere Befehle wie

exec("ls",$Ausgabe); print_r($Ausgabe);

funktionierten gut.

Ich habe 2>&1 am Ende meiner Befehle hinzugefügt, was es PHP anscheinend ermöglicht, sowohl den stderror-Inhalt als auch bei Erfolg stdout zu empfangen.

exec('git log 2>&1', $ausgabe); print_r($Ausgabe);

Jetzt konnte ich die eigentliche Fehlermeldung von git sehen:

dyld: Lazy Symbol Binding fehlgeschlagen: Symbol nicht gefunden: _iconv_open
Referenziert von: /Library/Developer/CommandLineTools/usr/bin/git
Erwartet in: /Applications/XAMPP/xamppfiles/lib/libiconv.2.dylib

dyld: Symbol nicht gefunden: _iconv_open
Referenziert von: /Library/Developer/CommandLineTools/usr/bin/git
Erwartet in: /Applications/XAMPP/xamppfiles/lib/libiconv.2.dylib

An diesem Punkt wurde mir klar, dass der Schuldige etwas mit einer "Konfigurationssache" in XAMPP zu tun hatte.

Ein Befehl wie git log funktioniert also vom Terminal aus, aber nicht von php exec().

Ich habe die Umgebungen zur genaueren Untersuchung in Textdateien exportiert.

printenv > ./env_php.txt - über php exec ausgeführt
printenv > ./env_terminal - über die Befehlszeile ausgeführt

Beim Vergleich dieser 2 Dateien habe ich gesehen, dass diese Umgebungsvariable:
DYLD_LIBRARY_PATH=/Applications/XAMPP/xamppfiles/lib:/Applications/XAMPP/xamppfiles/lib
war in der Umgebung vorhanden, in der PHP läuft.

Es kommt von:
/Applications/XAMPP/xamppfiles/bin/envvars
/Applications/XAMPP/xamppfiles/bin/envvars-std

Ich könnte mir vorstellen, dass einige Leute, die wamp, xampp oder andere *amp-Pakete verwenden, ähnliche Probleme haben.

Egal, ob ich nun Basic exec() oder eine Bibliothek verwende, die schließlich SymfonyComponentProcess (wie gitter) verwendet, alles, was ich tun muss, ist unset DYLD_LIBRARY_PATH hinzuzufügen
zum Anfang meines Befehls/Bash-Skripts
oder verwenden Sie putenv('DYLD_LIBRARY_PATH'); ?> irgendwo früh in meinem PHP-Code, um das Problem zu vermeiden.

Ich habe dieses Problem auf Centos 6 mit Symfony 2.6.0
Symfony 2.5.12 funktioniert einwandfrei

irgendeine Hilfe

Ich habe dieses Problem unter OS X 10.10 mit AMPPS, Apple-Git55. Jede Hilfe ist willkommen!

[SymfonyComponentProcessExceptionRuntimeException]
Der Vorgang wurde mit Signal "5" signalisiert.

Ausnahme-Trace:
() unter phar:///usr/local/bin/composer/vendor/symfony/process/Symfony/Component/Process/Process.php:367
SymfonyComponentProcessProcess->wait() at phar:///usr/local/bin/composer/vendor/symfony/process/Symfony/Component/Process/Process.php:210
SymfonyComponentProcessProcess->run() at phar:///usr/local/bin/composer/src/Composer/Util/ProcessExecutor.php:62
ComposerUtilProcessExecutor->execute() at phar:///usr/local/bin/composer/src/Composer/Package/Loader/RootPackageLoader.php:325
ComposerPackageLoaderRootPackageLoader->guessSvnVersion() at phar:///usr/local/bin/composer/src/Composer/Package/Loader/RootPackageLoader.php:193
ComposerPackageLoaderRootPackageLoader->guessVersion() at phar:///usr/local/bin/composer/src/Composer/Package/Loader/RootPackageLoader.php:59
ComposerPackageLoaderRootPackageLoader->load() at phar:///usr/local/bin/composer/src/Composer/Factory.php:268
ComposerFactory->createComposer() at phar:///usr/local/bin/composer/src/Composer/Factory.php:486
ComposerFactory::create() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:222
ComposerConsoleApplication->getComposer() at phar:///usr/local/bin/composer/src/Composer/Command/Command.php:53
ComposerCommandCommand->getComposer() at phar:///usr/local/bin/composer/src/Composer/Command/InstallCommand.php:82
ComposerCommandInstallCommand->execute() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Command/Command.php:257
SymfonyComponentConsoleCommandCommand->run() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:874
SymfonyComponentConsoleApplication->doRunCommand() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:195
SymfonyComponentConsoleApplication->doRun() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:146
ComposerConsoleApplication->doRun() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:126
SymfonyComponentConsoleApplication->run() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:82
ComposerConsoleApplication->run() at phar:///usr/local/bin/composer/bin/ composer:43
require() at /usr/local/bin/ composer:25

Leider habe ich eine kleine Anmerkung übersehen:
"Ich hatte das gleiche Problem, das von svn, Version 1.7.10 (r1485443) verursacht wurde. Ich habe svn in /usr/bin in /usr/bin/svn.orig umbenannt und meine Probleme wurden behoben."
Ich habe es gelöst.

endlich ist das Problem gefunden. Vielen Dank an die Support-Mitarbeiter von Rackspace Cristian Banciu und Mike Bostic

Ursache:
Der neueste newrelic PHP-Agent 4.23.1.107 verursacht einen Seg-Fehler, wenn er mit Symfony 2.6.0 oder höher mit der Prozesskomponente verwendet wird. newrelic.browser_monitoring.auto_instrument = 0 hat nicht geholfen

Lösung:
Endlich habe ich den Newrelic PHP-Agenten auf 4.21.0.97-1 herabgestuft und alles funktioniert einwandfrei

Stellen Sie sicher, dass Ihre Installation von Git mit Ihrem System kompatibel ist. Um dies zu überprüfen, führen Sie git describe --exact-match --tags .

Hey Leute, ich habe dieses Problem von oben nach unten durchgegangen und alle vorgeschlagenen Korrekturen implementiert und erhalte dieses Problem immer noch unter Mac OSX 10.10, wenn ich eine Laravel-App unseres Unternehmens installiert habe. Ich bin der einzige Entwickler, der Max OSX verwendet und alle anderen haben kein Problem. Hier ist die Ausgabe von Composer install --vvv

post-install-cmd: php artisan clear-compiled


  [Symfony\Component\Process\Exception\RuntimeException]
  The process has been signaled with signal "5".


Exception trace:
 () at phar:///usr/local/bin/composer/vendor/symfony/process/Process.php:375
 Symfony\Component\Process\Process->wait() at phar:///usr/local/bin/composer/vendor/symfony/process/Process.php:203
 Symfony\Component\Process\Process->run() at phar:///usr/local/bin/composer/src/Composer/Util/ProcessExecutor.php:62
 Composer\Util\ProcessExecutor->execute() at phar:///usr/local/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:204
 Composer\EventDispatcher\EventDispatcher->doDispatch() at phar:///usr/local/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:94
 Composer\EventDispatcher\EventDispatcher->dispatchScript() at phar:///usr/local/bin/composer/src/Composer/Installer.php:337
 Composer\Installer->run() at phar:///usr/local/bin/composer/src/Composer/Command/InstallCommand.php:134
 Composer\Command\InstallCommand->execute() at phar:///usr/local/bin/composer/vendor/symfony/console/Command/Command.php:259
 Symfony\Component\Console\Command\Command->run() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:844
 Symfony\Component\Console\Application->doRunCommand() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:192
 Symfony\Component\Console\Application->doRun() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:189
 Composer\Console\Application->doRun() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:123
 Symfony\Component\Console\Application->run() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:99
 Composer\Console\Application->run() at phar:///usr/local/bin/composer/bin/composer:43
 require() at /usr/local/bin/composer:24

install [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--no-plugins] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--ignore-platform-reqs] [--] [<packages>]...

Trace/BPT trap: 5

Hallo, ich habe einen Fehler bei der Installation von Composer mit osx el capitano v10.11, ich habe mamp v 4.1.1 in osx und php v7.
[SymfonyComponentProcessExceptionRuntimeException]
Der Vorgang wurde mit Signal "5" signalisiert.
Ich hänge den Fotofehler an
https://www.photobox.co.uk/my/photo/full?photo_id=9780357510

Habe den gleichen Fehler auch auf OSX capitano.

$ composer -vvv
Reading ./composer.json
Loading config file ./composer.json
Checked CA file /private/var/folders/89/7r_blf851pnb9w8rg22v6yt00000gn/T/composer-cacert-e62a07e61e5870effa81b430e1900778943c228bd7da1259dd6a955ee2262b47.pem: valid
Executing command (.../src/_tests/php-cs-fixer-config): git branch --no-color --no-abbrev -v
Executing command (.../src/_tests/php-cs-fixer-config): git describe --exact-match --tags
Executing command (.../src/_tests/php-cs-fixer-config): git log --pretty="%H" -n1 HEAD
Executing command (.../src/_tests/php-cs-fixer-config): hg branch
Executing command (.../src/_tests/php-cs-fixer-config): fossil branch list
Executing command (.../src/_tests/php-cs-fixer-config): fossil tag list
Executing command (.../src/_tests/php-cs-fixer-config): svn info --xml


  [Symfony\Component\Process\Exception\RuntimeException]  
  The process has been signaled with signal "5".          

$ svn
dyld: Library not loaded: /usr/lib/libcrypto.35.dylib
  Referenced from: /Library/Developer/CommandLineTools/usr/lib/libserf-1.0.dylib
  Reason: image not found
[1]    5221 trace trap  svn

Es ist also svn das Problem.
Aber da ich svn nicht benötige, kann das Verschieben einer ausführbaren Binärdatei diesen Fall lösen.

mv /usr/bin/svn /usr/bin/svn-bak

@emri99 Ich bestätige, dass genau das auch bei mir das Problem war. svn wurde nicht richtig installiert. Das Entfernen der Binärdatei ermöglicht es Composer, die Installation der Abhängigkeit fortzusetzen.

Bei mir hat das funktioniert:
$brew install svn
$brew link --subversion überschreiben

funktioniert bei mir.

@deondazy danke Mann

Ich hatte dieses Problem auch, verbrachte ungefähr 3 Stunden damit, es aufzuspüren. @deondazy- Lösung hat es auch für mich behoben. Danke @emri99 für den Hinweis auf den SVN-Fehler.

Drei mögliche Lösungen dafür.

1. Fügen Sie SVN zu Abhängigkeiten für Homebrew-Installationen hinzu. (einfach und würde wahrscheinlich für die meisten Leute lösen)
2. Ein ausführlicherer Fehler für SVN-Fehler.
3. git Fallback (oder verwenden Sie SVN als Fallback, da Git beliebter ist)

Ich bin mit der Codebasis des Komponisten nicht vertraut, aber ich bin bereit, die Machbarkeit meiner Vorschläge zu prüfen.

Danke an @PhilippeDunbar
Ich behebe das Problem im Mac.
brew install svn.

brauen subversion neu installieren

$brew upgrade subversion
$brew link --overwrite subversion

Mein Problem behoben