Ik probeer breekpunten in de GoogleAppEngine-bronnen (SDK 1.7.0) te plaatsen, maar IDEA Ultimate (11.0.2) blijft me vertellen Warning: No executable code found at line 482 in class com.google.appengine.api.memcache.AsyncMemcacheServiceImpl.
Ik krijg deze foutmelding zowel wanneer ik de code van unit tests uitvoer als ik de ontwikkelserver opstart.
Het is nogal vervelend. Hoe dan ook, mijn bronnen bevinden zich in een externe (ten opzichte van zowel de IDEA home als de project home) directory, en mijn jar-bestanden staan onder de Appengine SDK lib dir.
Mijn jar-bestanden zijn als projectbibliotheek aan de module toegevoegd en mijn bronnen zijn aan deze bibliotheek toegevoegd. Ik speelde ook met module-afhankelijkheden, maar zonder enig geluk. Uiteindelijk heb ik besloten om deze bibliotheek in Compile-scope te plaatsen, maar dat was een slecht idee aangezien de SDK deze jars tijdens runtime levert, dus besloot ik terug te vallen op Provided scope.
Ik speelde ook met de export checkbox op het tabblad module afhankelijkheden, maar ik denk dat dit niet relevant is, volgens de webhelp, exporteren is alleen belangrijk als u afhankelijke modules heeft en u uw bibliotheek ook in deze modules beschikbaar wilt maken.
Hoe dan ook, deze vraag ontstond 4 jaar geledenook. Dus ik vraag me nu af of het echt zo moeilijk is om dit probleem op te lossen?
Ik ben nu erg teleurgesteld. Ik had tot nu toe geen problemen met IDEA… Ik zag dat dit probleem is ook bij andere mensen ontstaan, dus dit is niet uniek denk ik.
Alle hulp wordt op prijs gesteld.
Ik heb mijn vraag aangepast vanwege mijn javap-experimenten hieronder: het lijkt erop dat de klassen en de bronnen NIETniet synchroon lopen. Ik heb de 1.7.0-gerelateerde revisie van SVN uitgecheckt en ik gebruik de 1.7.0 SDK, dus deze zouden helemaal niet synchroon moeten lopen.
Antwoord 1, autoriteit 100%
Ik had soortgelijke problemen en er zijn verschillende pogingen ondernomen. Hieronder staan mijn gebruikelijke stappen:
- Als u Maven-afhankelijkheden gebruikt, gaat u naar Maven Projects -> verversen
- Als dat niet werkt, probeer dan bovenmenu –> Bouw –> Project herbouwen
- Als dat nog steeds niet werkt, probeer dan het hoofdmenu –> Bestand –> Cache ongeldig maken/opnieuw opstarten
- Als dat nog steeds niet werkt, stop dan $CATALINA_BASE/bin/catalina.sh en start dan
Hierna dekt het meestal 99% van de problemen. Anders zult u waarschijnlijk een aantal andere mogelijkheden moeten onderzoeken.
Antwoord 2, autoriteit 26%
Ik had een soortgelijk probleem ondervonden tijdens het debuggen in Intellij. Ik kon geen breekpunt plaatsen bij een van de codefragmenten, daarna veranderde ik het regelnummer van de code en daarna kon ik het breekpunt plaatsen. Lijkt op een bug in intellij of een cachingprobleem.
Antwoord 3, autoriteit 11%
Ik heb een aantal andere gevallen gevonden waarin mensen meldden dat IDEA zegt: “Geen uitvoerbare code gevonden”. Een veelvoorkomend patroon is dat ze probeerden code te debuggen die is gebouwd zonder foutopsporingsinformatie. Controleer of je compileert met de “-g” vlag (of equivalent) set.
Antwoord 4, autoriteit 7%
Ik heb dit probleem kunnen oplossen door de betreffende klasse opnieuw te compileren:
Bouwen – > Hercompileren (bestandsnaam.java)
Antwoord 5, autoriteit 5%
De vraag is nogal oud, maar ik dacht dat mijn ervaring iemand in de toekomst zou kunnen helpen. In mijn geval probeerde ik code te debuggen die niet was gecompileerd met foutopsporingsinformatie. Ik gebruik maven waarin het originele bovenliggende pom-bestand vóór de wijziging er ongeveer zo uitzag als hieronder in de build-sectie.
<build>
<pluginManagement>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.1</version>
<configuration>
<target>${javaCompilerVersion}</target>
<source>${javaCompilerVersion}</source>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
<!--More plugins...-->
</pluginManagement>
</build>
Ik heb het bovenstaande gedeelte gewijzigd zodat het er zo uitziet als hieronder.
<build>
<pluginManagement>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.1</version>
<configuration>
<target>${javaCompilerVersion}</target>
<source>${javaCompilerVersion}</source>
<encoding>UTF-8</encoding>
<debug>true</debug>
<debuglevel>lines,vars,source</debuglevel>
</configuration>
</plugin>
<!--More plugins...-->
</pluginManagement>
</build>
Let op de toegevoegde elementen <debug>en <debuglevel>. het debuglevel-element kan elke combinatie van de drie argumenten hebben, gescheiden door komma’s.
Na het compileren van deze wijziging is het me eindelijk gelukt om breekpunten in IDEA te plaatsen.
Antwoord 6, autoriteit 5%
De essentie van het probleem is dat de JVM een klassenbestand uitvoert (ofwel een eenvoudige klasse of een klasse geladen vanuit jar vanuit het klassenpad) dat NIET OVEREENKOMT met de bron die door debugger wordt gebruikt.
Als dit eenmaal is begrepen, is de oplossing eenvoudig: zorg ervoor dat de bron de klasse vertegenwoordigt die wordt uitgevoerd.
Dus om het probleem op te lossen, kun je bronnen vernieuwen en synchroniseren met klassen, enz.
Antwoord 7, autoriteit 5%
Ik had hetzelfde probleem. Ik weet niet waarom, maar voor mij hielp het om elke wijziging in de code toe te voegen, zoals het toevoegen of verwijderen van commentaar. Vreemd, maar het heeft mijn probleem opgelost
Antwoord 8, autoriteit 4%
Menu –> Bestand –> Cache ongeldig maken/opnieuw opstarten
Dit werkte voor mij onder IntelliJ 13.0.2
Antwoord 9, autoriteit 2%
Ik had een soortgelijk probleem en het werd veroorzaakt door een fout in mijn Tomcat-configuratie, onder het tabblad Implementatie, “Implementeren bij het opstarten van de server”. Ik had het per ongeluk veranderd in een zeer vergelijkbaar project met “:war exploded”. Toen ik het terug veranderde, werkte het prima.
Antwoord 10, autoriteit 2%
Had hetzelfde probleem, kwam erachter dat de versie van de code op de server en degene die ik aan het opsporen ben verschillend zijn. Na het synchroniseren van de code was het probleem opgelost.
Antwoord 11, autoriteit 2%
In mijn geval was ik op afstand aan het debuggenen kwam ik erachter dat de versie van de code op de externe server en Intellijniet synchroon liep. Ik herbouwde de nieuwste code lokaal, plaatste dezelfde wijziging op de externe server en het werkte voor mij.
U kunt nog enkele mogelijke oplossingen uitproberen die specifiek kunnen zijn voor uw problemen, voorgesteld door JetBrains.
Onmogelijk om fouten op te sporen “Waarschuwing: geen uitvoerbare code gevonden op regel.”
Antwoord 12
Zorg er alstublieft voor dat u Proguard niet heeft gebruikt. Het heeft me geholpen.
Antwoord 13
Als je sommige servers gebruikt, gaan ze in de “lage geheugenmodus”, wat betekent dat ze niet voor je zullen debuggen, ongeacht welke opties of caches je ongeldig maakt.
U moet uw server stoppen, de geheugeninstellingen verhogen voor de opties die aan Java zijn doorgegeven en uw server opnieuw opstarten. Controleer logboeken om er zeker van te zijn dat u geen rapport krijgt zoals “running in low memory mode”.
Antwoord 14
In mijn geval heb ik alle actieve processen op het apparaat uitgeschakeld en de verbinding verbroken en opnieuw aangesloten.
Antwoord 15
Ik had hetzelfde probleem met het gebruik van debug-configuratie in mijn geval Tomcat.
Ik heb al het bovenstaande geprobeerd, maar niets.
toen ik de Tomcat net opnieuw configureerde (debug > configuratie bewerken > de tomcat verwijderen > opnieuw toevoegen) werkte het eindelijk 🙂
Antwoord 16
Controleer uw schijfruimte en maak een geheugen vrij. Als u bijna leeg bent op schijfruimte, zelfs als uw server niet op “Laag geheugenmodus” staat, zou Intellij de ruimte niet toewijzen aan de cache van de vereiste klassen die nodig zijn voor debugging. Hierdoor kan u het break-punt niet instellen.
Antwoord 17
Ik werkte aan een Intellij-plug-in en toen de Sandbox Intellij opduikte, wat uiteindelijk is opgelost, was mijn probleem, zodra de Sandbox Intellij opduikt, heb ik vanaf daar herbouwd.
Daarna bouwde ik zowel mijn intellijst en de sandbox intellij en ze hebben eindelijk gesynchroniseerd.
Antwoord 18
gewoon door het debuggingsproces te stoppen en het opnieuw te realiseren. In mijn geval, eenvoudig als dat.