https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
v
It just means that the daemon process quit. Not necessarily that there is any relation to heap memory.
e
is there a 
hs_err_pid.log
file left behind?
v
It could be some build logic or library used in the build logic that does 
System.exit(0)
It could be some SIGSEGV or other fatal JVM crash
It could be you doing 
kill -9 ...
on the commandline
It could be a system process thinking the process consumes too much RAM and thus killing it, where it would even be worse if you configure even more RAM
Many possibilities
So as @ephemient said, for example look for such crash logs if you can find them (they are not necessarily in the project directory, by default they are in the current work directory and this does not have to be the project directory)
👍 1
Maybe have a look at the daemon log files in 
<GRADLE_USER_HOME>/daemon/
whether there is something suspicious
Search in operator logs whether there was something like the OOM killer on linux killing it or some crash that was recorded by Windows event log, or by Ubuntu apport
...
e
or Console » Crash Reports on macos, or 
coredumpctl list
on most linux distros that aren't Ubuntu, etc.
v
I'm sorry, but it is virtually impossible to give a really targeted advice, that is all guesswork
👍 1
The error just means the daemon process was suddenly gone, fullstop
👍 1
n
No worries thank you for the info. We've only ever see than issue on CI when it related to some memory issues so thats why I mentioned it. Let me follow up with one of the engineers regarding a 
hs_err_pid.log
or crash report 👍
I have a daemon log if that's helpful and waiting on talking to another engineer about finding more crash reports
daemon-6265.out.log
v
Wouldn't have any idea why that deamon should suddenly die. Last it reused configuration cache and all tasks were up to date, so it did not even do work besides fingerprinting inputs.
👍 1
n
No 
hs_err_pid.log
or anything in Console > Crash Report 🙁
e
(fyi the jvm error log is not literally named that; 
pid
= the process id of the java process)
👍 1
n
There was no .log file in the directory the command was run in if that helps
v
That only helps if you know whether you maybe have configured a special place where to write those files to and if not, what the current working direcotry of the daemon process was, which as I said is not necessarily the project directory or the direcotry from where you call Gradle.
n
Ah okay I understood "current working directory" as the directory we called Gradle from. We don't have a super custom Gradle setup, is there a default working directory for where the daemon process was run we should check for logs?
v
No
It can be the project directory, it can be the daemon log directory, it can be the IDE installation directory (where you then probably would not find the files as you do not have write permissions), or probably other directories, that are just three of those I have encountered so far
👍 1
n
Wonderful thanks 😅 I'll keep an eye out in the directories you listed and will do more digging and will update the thread if I find anything else that could be relevant. Thanks to you both!
👌 1
5 Views
Open in Slack
PreviousNext
Powered by