Wesprzyj nas i przeglądaj Hejto bez reklam

Zostań Patronem
Hejto.pl
Hejto
/Wpisy
/Dyskusja
krokietowy
Fanatyk
w Programowanie
Mam problem w github CI, że projekt który kompiluję bierze całą dostępną przestrzeń dyskową.

Używam C++ i problem występuje przy linkowaniu - nie ważne czy używam lld, gold czy mold, zawsze jest to samo.

Da się coś na to zaradzić? Np. jest jakiś krok przed linkowaniem, który usuwa pliki źródłowe i zostawia tylko to co potrzebne do linkowania?

To jest krok z budowaniem aplikacji z address sanitizerem, więc nie mogę wyciąć żadnej opcji, która zmniejszyłaby rozmiar binarki.

#programowanie
#cpp
10

Komentarze (10)

mike-litoris

@krokietowy ustaw sobie ramdysk jako target do kompilacji, tam przechowywanie objfile zlinkują sięjak trzeba a po tym procesie zyskasz binarkę na fizycznym storage'u

krokietowy

@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)

mike-litoris

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

m_h

A nie dałoby rady budować bibliotek (.a) z poszczególnych komponentów i na koniec z linkować je do końcowej binarki?

mike-litoris

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

groman43

@krokietowy Z czystej ciekawości, co to za projekt. Bo to musi być niezła kobyła, w co nie za bardzo chcę mi się wierzyć.

vinclav

@groman43 podpinam się

krokietowy

@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: 00:53:34.621]

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

mike-litoris

@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?

krokietowy

@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)

Zaloguj się aby komentować