ANSI C getc provoca segfault no Linux, mas não OS X
-
06-07-2019 - |
Pergunta
Eu tenho algum código ANSI C que desenvolvi no meu Mac, mas quando eu tentei executá-lo em servidores Linux da nossa escola eu recebo um segfault.
A linha específica que está a causar-me problemas é um getc
de um ponteiro de arquivo.
O arquivo existe.
Aqui está o método em questão:
// inits lists with all data in fp file pointer
// returns # of lines read
int init_intlists(FILE *fp, INTLIST *lists[]) {
int c, ctr;
ctr = 0;
// need to use a linked list to store current number
// for non 1-digit numbers...
INTLIST *cur_num = NULL;
int cur_num_len = 0;
while ((c = getc(fp)) != EOF){
if(c != '\n' && c != ' '){
c = c - 48;
if(cur_num == NULL){
cur_num = init_intlist(c);
} else {
list_append(cur_num, &c);
}
cur_num_len++;
} else if(c == ' ' || c == '\n'){
// we reached a space, meaning we finished
// reading a contiguous block of digits
// now we need to figure out what we actually read...
int num = 0;
INTLIST *ptr;
ptr = cur_num;
while(cur_num_len != 0){
cur_num_len--;
num += pow(10, cur_num_len) * ptr->datum;
ptr = ptr->next;
}
if(lists[ctr] == NULL){
// init new list
lists[ctr] = init_intlist(num);
} else {
// append to existing
list_append(lists[ctr], &num);
}
// clear cur_num to read the next one
cur_num_len = 0;
list_delete(cur_num);
cur_num = NULL;
}
if(c == '\n') {
// newline reached - increment to fill in next list
ctr++;
}
}
return ctr;
}
A chamada para init_intlists
que faz com que o segfault começa assim:
FILE *fp = (FILE *)malloc(sizeof(FILE));
FILE *base_vector_fp = (FILE *)malloc(sizeof(FILE));
parse_args(argc, argv, fp, base_vector_fp);
if(fp == NULL || base_vector_fp == NULL){
fprintf(stderr, "Critical error, could not load input files\n");
return 1;
}
INTLIST *lines[MAX_LINES] = {};
INTLIST *base_vectors[MAX_LINES] = {};
int lines_read = init_intlists(fp, lines);
e olhares parse_args
como:
FILE *load_file(char *filename) {
FILE *fp;
fp = fopen(filename, "r");
if(fp == NULL){
fprintf(stderr, "File %s does not seem to exist.\n", filename);
return NULL;
}
// XXX Does this memory leak?
// fp is never fclose()'d
return fp;
}
void parse_args(int argc, char *argv[], FILE *fp, FILE *base_vector_fp) {
char *prog = argv[0];
if (argc != 3){
fprintf(stderr, "Wrong number of arguments supplied.\nUse: %s <data_filename> <base_vector_filename>\n", prog);
free(fp);
free(base_vector_fp);
fp = NULL;
base_vector_fp = NULL;
exit(1);
}
char *filename = argv[1];
*fp = *load_file(filename);
char *base_vector_filename = argv[2];
*base_vector_fp = *load_file(base_vector_filename);
}
Então, quando eu tento invocar esse no meu Mac, ele funciona perfeitamente bem e ele lê o arquivo em como deveria e eu sou capaz de operá-lo e obter as respostas corretas para o meu trabalho.
No entanto, quando eu tentar executá-lo no Linux, eu recebo um segfault quando ele tenta getc
na sub-rotina init_intlists
.
Eu tenho verificado que os arquivos que eu fornecer para exist entrada e são mundialmente legível (umask 755). Eu tentei com ambos os caminhos absolutos e relativos. Eu tentei vários arquivos de entrada diferentes também.
Eu tentei usar gcc 4.2
e gcc 3.4
no servidor Linux e ambos produzem um binário executável que irá causar um segfault com qualquer dado arquivos de entrada.
Aqui está a informação de versão entre as duas versões diferentes do gcc:
Mac OS X:
me@dinosaurhunter ~> gcc -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5465~16/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5465)
Linux:
me@janus:~/assignment_1$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu4)
invoco o compilador usando a mesma Makefile
em ambos OS X e Linux. A invocação final de gcc
acaba parecido com isto:
gcc -Wall -g -c src/common_file_io.c src/main.c src/intlist.c
gcc -Wall -g common_file_io.o main.o intlist.o -lreadline -lm -o bin/myprogram
Todas as idéias? Eu estou em uma perda completa, como é meu professor.
Solução
As outras respostas estão corretas - tratar uma FILE *
como um identificador opaco que você copia ao redor, não tente copiar seu conteúdo. Especificamente, você pode corrigir o seu código da seguinte forma:
Remova a chamada para malloc
quando você inicializar fp
e base_vector_fp
:
FILE *fp = NULL;
FILE *base_vector_fp = NULL;
Passar um ponteiro para esses ponteiros para parse_args
, para que ele possa atualizar os valores de ponteiro:
parse_args(argc, argv, &fp, &base_vector_fp);
E a mudança parse_args
para atualizar os objetos FILE *
no chamador, em vez de tentar trabalhar com os objetos FILE
:
void parse_args(int argc, char *argv[], FILE **fp, FILE **base_vector_fp) {
char *prog = argv[0];
if (argc != 3){
fprintf(stderr, "Wrong number of arguments supplied.\nUse: %s <data_filename> <base_vector_filename>\n", prog);
exit(1);
}
char *filename = argv[1];
*fp = load_file(filename);
char *base_vector_filename = argv[2];
*base_vector_fp = load_file(base_vector_filename);
}
Outras dicas
Você não é suposto para alocar seus próprios objetos FILE
, eles são geralmente objetos opacos geridos pela libc. Não free()
-los também, que é feito por fclose(3)
. Embora, teoricamente, você poderia atribuir uma e fazer um atribuir estrutura e tê-lo trabalhar, seria melhor não combater a biblioteca e apenas passar em torno da referência como todo mundo faz. A biblioteca pode ou não manter o estado que não está na estrutura do arquivo, e espreitar dentro ou dereferencing toda a estrutura é suficientemente mau estilo que os implementadores pode realmente assumir que você nunca fazê-lo.
Se você quiser retornar um FILE *
você pode usá-lo como um valor de ponteiro de retorno como você fez em um caso ou usar um ponteiro duplo indireta:. FILE *fp; f(&fp);
Hmm, eu só notei que C99 realmente especifica isso na 7.19.13 :
6 O endereço do objeto de arquivo usado para controlar um fluxo pode ser significativo; uma cópia de um objeto de arquivo não precisa servir no lugar do originais.
Com isso, eles são um pré-aviso de que uma FILE *
pode realmente ser apenas um cookie mágico.
Você não deve copiar o resultado offopen()
into aFILE
object, e na verdade, você deve notmalloc
aFILE
object em tudo. Você deve sempre usefopen()
to alocar theFILE
control objeto.
TheFILE
object é opaco e, em verdade ele contém muito do que está escondido para meros mortais. A implementação é livre para colocar todos os tipos de coisas nele, tais como ponteiros para outras estruturas de controle, etc.