@mike-litoris Ramu w github CI jest chyba tylko 7GB i większość jest używana, więc raczej to nie jest mozliwe(nie wiem czy ramdysk w CI jest możliwy do zrobienia)

@krokietowy do rzeczy, jaki masz błąd, ile logów jesteś w stanie załączyć?

@m_h a czasem nie tak działa proces kompilacji i linkowania wszystkich śmieci do ELF'a?:D

@groman43 podpinam się

@groman43 Ano kobyła, dużo zależności nie linkowanych dynamicznie, ale wklejanych bezpośrednio w projekt.

Razem z zależnościami, ma 1.8 miliona linii w C i podobną ilość w C++.

Niestety projekt prywatny, więc nie mogę udostępnić.

@mike-litoris

Bezpośredni błąd to:

Unhandled exception. System.IO.IOException: No space left on device : '/home/runner/runners/2.315.0/_diag/Worker_20240410-010354-utc.log'

  at System.IO.RandomAccess.WriteAtOffset(SafeFileHandle handle, ReadOnlySpan`1 buffer, Int64 fileOffset)

  at System.IO.Strategies.BufferedFileStreamStrategy.FlushWrite()

  at System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)

  at System.Diagnostics.TextWriterTraceListener.Flush()

  at System.Diagnostics.TraceSource.Flush()

  at GitHub.Runner.Common.TraceManager.Dispose(Boolean disposing)

  at GitHub.Runner.Common.TraceManager.Dispose()

  at GitHub.Runner.Common.HostContext.Dispose(Boolean disposing)

  at GitHub.Runner.Common.HostContext.Dispose()

  at GitHub.Runner.Worker.Program.Main(String[] args)

System.IO.IOException: No space left on device : '/home/runner/runners/2.315.0/_diag/Worker_20240410-010354-utc.log'

  at System.IO.RandomAccess.WriteAtOffset(SafeFileHandle handle, ReadOnlySpan`1 buffer, Int64 fileOffset)

  at System.IO.Strategies.BufferedFileStreamStrategy.FlushWrite()

  at System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)

  at System.Diagnostics.TextWriterTraceListener.Flush()

  at GitHub.Runner.Common.HostTraceListener.WriteHeader(String source, TraceEventType eventType, Int32 id)

  at GitHub.Runner.Common.HostTraceListener.TraceEvent(TraceEventCache eventCache, String source, TraceEventType eventType, Int32 id, String message)

  at System.Diagnostics.TraceSource.TraceEvent(TraceEventType eventType, Int32 id, String message)

  at GitHub.Runner.Worker.Worker.RunAsync(String pipeIn, String pipeOut)

  at GitHub.Runner.Worker.Program.MainAsync(IHostContext context, String[] args)

System.IO.IOException: No space left on device : '/home/runner/runners/2.315.0/_diag/Worker_20240410-010354-utc.log'

  at System.IO.RandomAccess.WriteAtOffset(SafeFileHandle handle, ReadOnlySpan`1 buffer, Int64 fileOffset)

  at System.IO.Strategies.BufferedFileStreamStrategy.FlushWrite()

  at System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)

  at System.Diagnostics.TextWriterTraceListener.Flush()

  at GitHub.Runner.Common.HostTraceListener.WriteHeader(String source, TraceEventType eventType, Int32 id)

  at GitHub.Runner.Common.HostTraceListener.TraceEvent(TraceEventCache eventCache, String source, TraceEventType eventType, Int32 id, String message)

  at System.Diagnostics.TraceSource.TraceEvent(TraceEventType eventType, Int32 id, String message)

  at GitHub.Runner.Common.Tracing.Error(Exception exception)

  at GitHub.Runner.Worker.Program.MainAsync(IHostContext context, String[] args)

Jednak przy bliższym przepatrzeniu, okazało się że to nie bezpośrednio problem linkowania, ale kopiowania po linkowaniu - nie mogę niczego podobnego znaleźć w sconstruct(używamy scons) i wygląda mi to trochę jakby to sam scons wykonywał to topiowanie

scons -j2

Linking Static Library core/libitem.x86_64.a ...

Ranlib Library core/libitem.x86_64.a ...

Linking Program bin/project.x86_64 ...

scons: done building targets.

[Time elapsed: 0034.621]

cp: error writing '../project.x86_64': No space left on device

@krokietowy Stacktrace z runnera też niespecjalnie pomoże bo to tylko "bardziej rozpisane" wszystko dookoła źródłowego błędu braku miejsca.

Rozumiem jednak warunki NDA i spróbuję się dostosować.

Na początkek zacząłbym chyba od sklonowana repo lokalnie i zrobienia tego wszystkiego co robi runner, z odpaleniem sconsa na czele. Tam będziesz mieć rozpisane wszystkie kroki budowania binarki (bo nie samej kompilacji) i to tam musisz poszukać oszczędności.

Jeśli przykładowo to co kodzisz to software'owy emulator risc-v który składa się z emulator-x86 i libemulator to zasada jest taka żeby najpierw zbudować libemulator i trzymać już gotową bibliotekę, a potem zbudować część kliencką i dołączyć libemulator do klienta.

Do dołączania (linkowania) nie potrzebujesz nic poza samym libemulator.so oraz libemulator.a. Istnieje więc opcja takiego podzielenia procesu budowania żeby po udanym zbudowaniu biblioteki posprzątać wszystkie pliki pośrednie (.o) czy nawet kod źródłowy (bo skoro budujesz z ci/cd to za każdym razem runner robi sobie klona i odpala entrypoint).

Ja bardziej siedzę w Makefile'ach, SConstructa tylko używałem jako "klient" ale jak dobrze kminię to to właśnie tam powinieneś spróbować się podczepić i przemieszać w procesie buildu.

Jesteś w stanie np podmienić w sconsie wszystkie wrażliwe, unikalne nazwy na coś generycznego i wrzucić plik na pastebina?

@mike-litoris W repo są 3 pliki sConsturct po 500 linii i masa plików scsub, więc nie do końca wiem gdzie to szukać i nie chce mi się tego zbytnio anonimizować. Przepatrzę czy można rozbić czyszczenie, ale nie jestem w tym zbyt dobry, wiec pewnie wymięknę, bo wstępnie nie mogłem znaleźć nic ciekawego

Z address sanitizerem, potrzebne mi są jedynie numery linii i nazwy samych linii by znaleźć problem.

Czytałem że chyba opcja `-g` dorzucana do kompilacji(a która jest obecnie używana w repo - -g3 albo -g2) jest używana przy debugowaniu - a ja nie chcę debugować aplikacji tylko znaleźć info z symboli linii. Na próbę to wyłączę i zobaczę czy to może pomóc(samo budowanie aplikacji trwa z godzinę, więc rezutaty będę znał dopiero po tym czasie)