Avatar billede heyn Nybegynder
06. august 2013 - 09:36 Der er 13 kommentarer og
1 løsning

Skader det at fjerne fflush(NULL) ?

Hej Eksperter

Jeg har nogle problemer med et program der er ustabilt men det er ikke i en speciel situation det sker, det virker tilfældigt. Nogle gange virker programmet, andre gange ikke. Vi er ved at få grå hår fordi NETS sætter spørgsmålstegn ved vores pilot test.

Vi kan dog se at programmet, når det sker, ikke udskriver selv om det ikke er selve problemet.

Programmet anvender CallBack funktioner.

Noget af programmet var allerede udviklet af andre som et eksempel, så noget af koden havde jeg ikke undersøgt nærmere.

Nu opdager jeg at der findes et par fflush(NULL) statements i nogle funktioner der foretager udskrift til fil.

På nettet kan jeg bare finde noget om at det påvirker input/output og er godt at anvende ved udvikling.

Hvad betyder dette præcist? Hvad er den fulde konsekvens?

Venligst Christian
Avatar billede arne_v Ekspert
06. august 2013 - 14:48 #1
DESCRIPTION

    If stream points to an output stream or an update stream in which the most recent operation was not input, fflush() causes any unwritten data for that stream to be written to the file, and the st_ctime and st_mtime fields of the underlying file are marked for update.

    If stream is a null pointer, fflush() performs this flushing action on all streams for which the behaviour is defined above.
Avatar billede arne_v Ekspert
06. august 2013 - 14:51 #2
Det lyder ikke som noget der giver problemer.

Lidt sjusket bare at flushe alt i.s.f. at flushe praecis det der er skrevet til, men ....

Jeg er ret sikker paa at fejle ligger et andet sted. Noget undefined behavior / memory overskrivning eller lignende.

Compiler du med -Wall?

har du proevet at koere diverse checkers paa koden for at se om der er noget der er suspekt?
Avatar billede heyn Nybegynder
06. august 2013 - 15:11 #3
Jeg har prøvet en del.
Men det sure er at vi ikke længere kan fremprovokere fejlen på vores egen terminal (uden at fflush(NULL) var fjernet.

Men kunden oplever det stadig.

Det eneste vi har gjort er at flytte dankortterminalen fra /dev/ttyS2 til /dev/ttyS1. Det gjorde at den fik IRQ 3 og ligger med større rettighed end det meste andet.

Ja - Og så udskriver vi nu et par enkelte statusmeddelelser til en fil ved programstart før dankortterminalen sender nogle og dermed bliver filen oprettet tidligere.

Hvis en fil er i fopen mode, evt. under oprettelse - Vil det så give programnedbrud hvis andre programmer også åbner filen for at læse i den, prøver at slette den el. skrive til den?

Venligst Christian
Avatar billede heyn Nybegynder
06. august 2013 - 15:19 #4
Ja jeg compiler med wall

En anden har været så venlig at bygge makefile og den har følgende

CFLAGS  =  -c -O2 -g0 -DBUILDING_LINUX_DLL -D_P_ALIGNED_=packed -fsigned-char -Wall -Wsign-compare $(INCLUDE) -fno-exceptions

Den gang jeg anvendte Borland C++ syntes jeg det var lidt mere tilgængeligt :)
Avatar billede arne_v Ekspert
06. august 2013 - 15:36 #5
At skifte fra -O2 til -O0 kunne maaske goere det nemmere at finde fejlen.
Avatar billede arne_v Ekspert
06. august 2013 - 15:36 #6
Borland compileren havde stort set de samme options.

De var bare gemt vaek af IDE'en.
Avatar billede heyn Nybegynder
06. august 2013 - 16:02 #7
Nej - det gjorde ingen forskel. Det compileren skriver i terminalen er helt ens.

Det eneste jeg overhovedet kan komme i tanke om er det med filerne.

Programmøren der læser/sletter filer er her bare ikke fordi han har ferie til mandag, så jeg kan ikke spørge ham hvornår i processen han gør det.

Nå - Så må jeg vente på ham.

Ville dette med at det andet program åbner og evt. slette filer få mit program til at crache el. evt gå i selvspind hvis det skete mens mit program var i fopen mode? Hvis det gør kunne det nemlig være årsagen til at det sker så uregelmæssigt.

Smid under alle omstændigheder et svar.

Venligst Christian
Avatar billede heyn Nybegynder
06. august 2013 - 17:06 #8
Vi begynder virkelig at tro at det har noget med indlæsning af konfigurations filen at gøre fordi det andet program også bruger denne fil når den skal hente forskellige data om opsætning af terminalen.

Har du erfaring med den slags på Linux? Altså at 2 programmer åbner en fil samtidig.
Avatar billede arne_v Ekspert
07. august 2013 - 03:57 #9
Jeg er ikke klar over hvordan det staar til med shared access af filer i Linux.

Kan du ikke lave to smaa test programmer for at undersoege?
Avatar billede heyn Nybegynder
07. august 2013 - 10:54 #10
Du glemte svaret :)

Det kunne jeg selvfølgelig. Det er bare svært fordi vi dels ikke længere kan fremkalde problemet hos os selv, kun hos kunden, og desuden fordi problemet opstår så uregelmæssigt.
Årsagen til den sidste del af mit spørgsmål var nemlig at hvis conf filen allerede ligger i cache skal mit program ikke hente den i ram'en og ville derfor nå indlæsningen inden det blev det andet programs 'tur' til at arbejde.

Hvis derimod der har været mange transaktioner uden kort vil conf filen være skubbet ud i rammen el. endda helt ud på disk. det vil da tage så lang tid at det vil blive det andet (JavaScript) programs 'tur' til at arbejde.

HVIS altså det med at flere læser på samme fil er et problem kunne det være forklaringen.

Det ville også forklare hvorfor andre programmører ikke oplever det samme ved deres udvikling (Kortterminalproducenterne står også helt på bar bund). De fleste udvikler til et Windows miljø (som jo ikke er flerbruger), og integrerer desuden deres program således at det ikke stopper mellem transaktionerne (á pro pos spm. 984110).

Nå - Jeg vil i indlæsningen tilføje et while loop på max. 3 og sleep(1) indbygget der samtidig tester om conf filen indlæses korrekt og ellers terminerer før transaktionen starter for alvor.

Hvis det lykkes så vil den mulighed for fejl være elimineret og hvis det lykkes vil NETS ikke klage over timeout i transaktioner.

Venligst Christian

P.s. Husk nu svaret :)
Avatar billede arne_v Ekspert
08. august 2013 - 03:43 #11
svar
Avatar billede arne_v Ekspert
08. august 2013 - 03:43 #12
mit forslag var ikke at teste med det rigtige program men med specielle test programmer som tilgaard fil samtidigt
Avatar billede heyn Nybegynder
08. august 2013 - 08:11 #13
Ok - Tak for al hjælpen.
Jeg vil også prøve at læse mere om at sætte lock på filer/se om de lock'ede.
MÅSKE sætter Mozilla lock på filer mens den arbejder med dem. Hvem ved.
Avatar billede segmose Nybegynder
10. august 2013 - 02:26 #14
Hmm mon din /dev/ttyS2 er sat forkert op i dit/kundens system?
prøv at køre en dmesg og vis alle linier med /dev/ samt linien lige før og efter. De kommer muligvis 2-3 gange.
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
Kurser inden for grundlæggende programmering

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester