Plantage du projet lors de l'appel à la commande System

**CleeM** · 08/08/2012, 17h55

Bonjour à tous,

Depuis peu, lorsque je lance la commande System, mon programme plante.
Par exemple, j'essaye un simple System("pause") et mon programme plante.

J'ai pourtant toutes les libs/headers nécessaire à l'appel de cette fonction.

Je vous joins tous mes includes, au cas où certains feraient planter la fonction :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#ifdef WIN32
	#include <winsock2.h>
	#include <Windows.h>
#elif defined (linux)
	#include <sys/types.h>
	#include <sys/socket.h>
	#include <netinet/in.h>
	#include <arpa/inet.h>
	#include <unistd.h> // GetHostName
	#include <netdb.h>
	#define INVALID_SOCKET -1
	#define SOCKET_ERROR -1
	#define closesocket(s) close(s)
	typedef int SOCKET;
	typedef struct sockaddr_in SOCKADDR_IN;
	typedef struct sockaddr SOCKADDR;
	typedef struct in_addr IN_ADDR;
#else
	#error not defined for this platform
#endif
 
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <vector>
 
#pragma comment(lib,"ws2_32.lib")

Je n'ai rien changé à ce niveau là depuis un moment je trouve donc ça très étrange !
Et dans les propriétés de mon projet, tout est normal (enfin rien de changé récemment aussi!).

PS: J'exécute le programme sous Windows, pour les #ifdef.

**Neckara** · 08/08/2012, 21h48

Ton programme plante, mais quel est le message d'erreur? Segfault ?

Sinon system ne prend pas de majuscule il me semble.

Et une dernière chose, on est en C++ pas en C donc pour les includes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
#include <cstdio>
#include <cstdlib>
#include <cstring>

**CleeM** · 09/08/2012, 14h04

Merci pour les infos, je ne savais pas que l'appel aux libs était différent

Quand à l'erreur, oui c'est une segfault. Donc je n'arrive pas à avoir plus d'infos sur l'erreur :/

**Jean-Marc.Bourguet** · 09/08/2012, 14h19

Envoyé par Neckara

Et une dernière chose, on est en C++ pas en C donc pour les includes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
#include <cstdio>
#include <cstdlib>
#include <cstring>

Pure preference stylistique. Et on a parfois des raisons non stylistiques de preferer la version .h pour certains entetes (en particulier sous Unix on a parfois des declarations additionnelles dans ces fichiers -- a l'origine certains sont des fichier de Unix qui ont ete partiellement standardise en C -- qui sont absentes avec la version cxxx et presentes avec xxx.h) donc le faire systematique pour tous a du sens.

**Neckara** · 09/08/2012, 14h34

Je croyais qu'avec les xx.h, on avait l'implémentation C et avec les cxx on avait l'implémentation plus orienté C++.

Comme pour la fonction strcpy de cstring où on va faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

while(chaine1++ = chaine2++);

Chose qui ne marcherait pas en C.

Je doute qu'ils se soient amusés à refaire un certain nombres d'en-têtes standards juste pour des raisons stylistiques.

Il me semble aussi que string.h est obsolète (d'après la FAQ C++), donc ce doit aussi être le cas d'autres header en .h comme iostream.h ?

Toujours d'après la FAQ :

Envoyé par http://cpp.developpez.com/faq/cpp/?page=console#SL_iostream

Il est en de même avec tous les fichiers d'en-tête standards en C++, y compris avec ceux de la bibliothèque standard C. Pour des raisons d'uniformisation, il faut désormais les inclure sans le .h et en préfixant leur nom par la lettre c (pour souligner le fait qu'ils sont issus du C).

EDIT : ton segfault viens du fait que tu as écris n'importe où en mémoire il faut donc t'armer de patience et relire tout ton code.

**Jean-Marc.Bourguet** · 09/08/2012, 16h02

Envoyé par Neckara

Je croyais qu'avec les xx.h, on avait l'implémentation C et avec les cxx on avait l'implémentation plus orienté C++.

Normativement en C++11, la seule difference entre xxx.h et cxxx, c'est que dans le premier cas les declarations sont a coup sur presentes dans le namespace global et peut-etre dans le namespace std, tandis que pour cxxx, les declarations sont a coup sur presentes dans std et peut-etre dans le namespace global. Avant, la garantie etait un peu plus forte pour cxxx; mais en pratique les implementations n'y obeissaient pas toutes.

En pratique, il y a une autre difference: les declarations demandees par d'autres normes comme POSIX pour les versions xxx.h etaient toujours presentes (quand demandees par ces normes) dans xxx.h quand j'ai teste, la situation variait pour cxxx. C'est une bonne raison de preferer xxx.h (surtout quand par ailleurs on inclus des entetes purement POSIX comme unistd.h, ce que fait l'OP).

Oui la forme xxx.h est deprecated avec comme signification Normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions ce qui ne veut pas dire grand chose on a vire des choses qui ne l'etaient pas; on en a conserve qui l'etaient (j'ai meme le vague souvenir qu'il y en a qui l'etaient et qui non seulement ont ete conservees mais ne sont plus deprecated).

Comme pour la fonction strcpy de cstring où on va faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

while(chaine1++ = chaine2++);

Chose qui ne marcherait pas en C.

Et ça marche en C++? (Le resultat de ++ postfixe sur un pointeur n'est pas une rvalue).
Par contre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

while (*chaine1++ = *chaine2++);

devrait fonctionner en C et en C++. Et surtout, on se fout de l'implementation.

Je doute qu'ils se soient amusés à refaire un certain nombres d'en-têtes standards juste pour des raisons stylistiques.

Tu as encore des illusions a perdre.

Il me semble aussi que string.h est obsolète (d'après la FAQ C++) donc ce doit aussi être le cas d'autres header en .h comme iostream.h ?

Attention. Les formes en .h, c'est pour les fichiers provenant du C. iostream ne provient pas du C, en inclusant iostream.h, Dieu seul sait ce que tu auras (au choix, une erreur, <iostream> avec un using std;, <iostream> avec des using plus selectifs, une implemetation des stream non templatees et compatible avec ce que fournissait ton fournisseur avant la norme).

Pour string, on a <string.h> et <cstring> avec la difference expliquee ci-dessus et <string> qui definit le type std::string. Il y a aussi un <strings.h> sous Unix.

**CleeM** · 09/08/2012, 16h09

Merci pour tous ces détails sur les includes, même si ce n'était pas le sujet de base je suis content d'avoir lancé un débat !

Quand à mon souci de SegFault, quand tu dis que j'ai écrit n'importe où en mémoire, tu veux dire que je n'ai pas fait attention aux news/delete ; malloc/free ou autre chose? Car à ce niveau je fait attention normalement!

**Neckara** · 09/08/2012, 17h22

Envoyé par Jean-Marc.Bourguet

Et ça marche en C++? (Le resultat de ++ postfixe sur un pointeur n'est pas une rvalue).
Par contre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

while (*chaine1++ = *chaine2++);

devrait fonctionner en C et en C++. Et surtout, on se fout de l'implementation.

J'ai en effet oublié les '*', ces temps-ci je fais pas mal d'erreurs bêtes dans mes codes.

Pour contre, je confirme que ce code ne marchera pas en C.
En effet, le premier octet ne sera pas copié.

Envoyé par Jean-Marc.Bourguet

Attention. Les formes en .h, c'est pour les fichiers provenant du C. iostream ne provient pas du C, en inclusant iostream.h, Dieu seul sait ce que tu auras (au choix, une erreur, <iostream> avec un using std;, <iostream> avec des using plus selectifs, une implemetation des stream non templatees et compatible avec ce que fournissait ton fournisseur avant la norme).

L'exemple de iostream.h a été pris dans la FAQ.

Merci pour ces renseignements sur la différence entre cxx et xx.h

Pour le segfault, ce n'est pas forcément la faute de news/delete mais par exemple la faute de pointeurs, dépassement de tableau...
Par contre dans un code en C++ on évite d'utiliser malloc et free.
Après même en faisant attention, il est impossible de ne pas faire d'erreurs.

**Jean-Marc.Bourguet** · 09/08/2012, 17h34

Envoyé par Neckara

Pour contre, je confirme que ce code ne marchera pas en C.
En effet, le premier octet ne sera pas copié.

J'aimerai bien savoir pourquoi. Avec les références nécessaires pour convaincre les développeurs de gcc, Sun et IBM qu'il y a un bug à ce sujet dans leurs compilateurs.

**Neckara** · 09/08/2012, 17h54

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
void strcpy(char * chaine1, char * chaine2)
{
         while(*chaine1++ = *chaine2++);
}

En C++ :
- on stocke la valeur de chaine1, on l'incrémente et on retourne la valeur enregistrée ;
- on fait de même avec chaine2 ;
- on récupère la valeur contenu dans la mémoire pointée par l'ancienne valeur de chaine2 (on va la nommer c) ;
- on copie cette valeur c dans la mémoire pointé par l'ancienne valeur de chaine1 ;
- si cette valeur c n'est pas 0 ( '\0') on continu sinon on s'arrête.
(Ce n'est pas forcément dans le bon "ordre" mais peu importe)

Ainsi on copie tous les octets, du premier au '\0'.

En C, l'opérateur i++ fait la même chose que ++i en C++, ce qui donne :
- on incrémente la valeur de chaine1 ;
- on incrémente la valeur de chaine2 ;
- on récupère la valeur contenu dans la mémoire pointée par la nouvelle valeur de chaine2 (on va la nommer c) ;
- on copie cette valeur c dans la mémoire pointé par la nouvelle valeur de chaine1 ;
- si cette valeur c n'est pas 0 ( '\0') on continu sinon on s'arrête.

Ainsi on incrémente les pointeurs avant de copier le premier octet, il ne sera donc jamais copié.

screetch · 09/08/2012, 18h00

euh, non. x++ et ++x fonctionnent pareil en C et C++, non?
De plus, meme si c'etait le cas, string.h et cstring ne contiennent pas deux implementations differentes mais simplement cstring contient un alias sur strcpy accessible depuis le namespace std. Cet alias peut etre implemente comme tu veux (une version est effectivement de reimplementer la foction) mais le cas general est d'avoir cstring comme ca:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
#include <string.h>
namespace std
{
    using ::strcpy;
}

aucune reimplementation

**Neckara** · 09/08/2012, 18h03

En C, i++ et ++i revient au même, on incrémente i et on retourne sa valeur.
En C++, ++i est l'équivalent du i++ et ++i du C mais i++ va stocker la valeur de i avant de l'incrémenter et de retourner la valeur stockée.

EDIT : je vais tout de même tester.

screetch · 09/08/2012, 18h04

j'ai beau chercher, je ne trouve que des documents qui disent le contraire.

**CleeM** · 09/08/2012, 18h05

Sa fait un bon moment que je bloque sur cette erreur, sa vous va si je vous colle une partie de mon code pour voir si vous trouvez? Je ne suis pas encore très à l'aise avec certaines notions de pointeurs.

J'ai un programme assez conséquent, mais après plusieurs tests, je suis sur que l'erreur viens de la fonction sur laquelle je suis en train de travailler.

Je vous mets le code de la fonction. En gros, cette fonction permet de lancer une sauvegarde MySQL avec l'outil mysqldump (qui doit être lancé en ligne de commande avec donc la commande system) sur une named pipe, puis lis le résultat du dump sur cette même pipe.
Vu que mysqldump écrit une named pipe et que la commande permettant de lire sur la pipe est bloquante, j'ai utilisé un thread pour lancer le mysqldump et je lance la lecture du pipe à la suite de ma fonction.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
BOOL error_result		= TRUE;
Int32 error_test		= NULL;
char* mysqldump_db_string	= NULL;
char* recv_data			= NULL;
LPCWSTR pipe_name		= NULL;
char* char_pipe_name		= NULL;
HANDLE pipe			= NULL;
HANDLE thread			= NULL;
 
pipe_name = L"\\\\.\\pipe\\mysqldump";
char_pipe_name = "\\\\.\\pipe\\mysqldump";
 
// Contruction of the mysqldump exec string
mysqldump_db_string = (char*)malloc(33+strlen(ConSQL->repertory)+strlen(ConSQL->login)+strlen(ConSQL->password)+strlen(ConSQL->instance)+strlen(ConSQL->database)+strlen(char_pipe_name));
sprintf(mysqldump_db_string, "\"\"%smysqldump.exe\" -u %s -p%s -P %s \"%s\" > \"%s\"\"", ConSQL->repertory, ConSQL->login, ConSQL->password, ConSQL->instance, ConSQL->database, char_pipe_name);
 
// Create the Named Pipe
printf("Creating the named pipe...\n");
pipe = CreateNamedPipe(
	pipe_name, // name of the pipe
	PIPE_ACCESS_DUPLEX, Read/Write
	PIPE_TYPE_BYTE,// send data as a byte stream
	1, // only allow 1 instance of this pipe
	0, // no outbound buffer
	0, // no inbound buffer
	0, // use default wait time
	NULL // use default security attributes
	);
if(pipe == NULL || pipe == INVALID_HANDLE_VALUE)
{
	printf("Failed to create the named pipe: %s\n", char_pipe_name);
	return 1;
}
 
 
// Execute the mysqldump using a thread
printf("Launching MySQLDump Thread...\n");
thread = CreateThread(NULL, 0, &Thread_MySQLDump, (LPVOID)&mysqldump_db_string, 0, NULL);
if( thread == NULL )
{
	printf("Failed to launch the MySQLDump Thread!\n");
	return 2;
}
 
 
// This call blocks until a client process connects to the pipe
printf("Waiting for a connection...\n");
error_result = ConnectNamedPipe(pipe, NULL);
if (!error_result)
{
	printf("Failed to make connection on named pipe\n");
	CloseHandle(pipe);
	return 3;
}
printf("Connected!\n");
 
/*
ICI je continue en lisant sur la pipe avec ReadFile
*/

Voilà ce que j'ai essayé :
- Ne pas lancer le thread : plante au bout d'un moment lorsqu'il attends une connexion sur la named pipe.
- Lancer le thread : plante assez rapidement sans arriver à exécuter ce qu'il y a dans le thread (même pas un petit printf).
- Ne pas lancer le thread et lancer le mysqldump à l'extérieur du programme : récupère une partie du message et plante.

Voilà, si jamais vous avez une idée quelconque je suis preneur, sinon je reprendrais à 0 ma fonction demain, car là je suis un peu perdu!

screetch · 09/08/2012, 18h07

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

(char*)malloc(33+strlen(

il vient d'ou le 33? je compote au moins 36 et j'ai arrete avant la fin.
aussi ca me parait pas tres perenne.
Essaye avec 2000 pour voir c'est pas un fix propre mais ca permet de cerner le probleme

**Kiroxas** · 09/08/2012, 18h13

Envoyé par Neckara

En C, i++ et ++i revient au même, on incrémente i et on retourne sa valeur.

Non, non, non. Ou alors kernighan & ritchie ce sont trompé en écrivant le K&R et tout le monde jusqu'à ce jour les as suivis. Ils donnent exactement cet exemple de strcpy et wiki aussi d'ailleurs (reprise du livre).
Je te conseil la lecture du K&R, très bon livre

.

**Neckara** · 09/08/2012, 18h13

D'après mes tests, vous avez raison, i++ et ++i sont différents en C.

J'avais compris en lisant la FAQ C++ que les personnes faisant du C mettaient souvent i++ à la place ++i car en C, i++ et ++i étaient identiques et comme en cours de C, on apprend juste le i++ et on nous dis juste qu'il incrémente i...

Envoyé par http://cpp.developpez.com/faq/cpp/?page=surcharge#SURCHARGE_rapidite_pp

Les programmeurs habitués à faire du C ont l'habitude d'écrire i++ plutôt que ++i. [...]
De toute évidence, quand i++ apparaît en tant que partie d'une expression plus complexe, la situation est différente : il est utilisé parce que c'est la seule solution logique et correcte et non pas parce qu'il s'agit d'une habitude héritée de l'époque ou l'on codait du C.

Autant pour moi.

**Jean-Marc.Bourguet** · 09/08/2012, 18h29

Envoyé par Neckara

En C, l'opérateur i++ fait la même chose que ++i en C++, ce qui donne

J'aimerais bien les références qui contredisent:

Envoyé par C90 6.3.2.4

The result of the postfix ++ operator is the value of the operand. After the result is obtained, the value of the operand is incremented.

Meme chose en C99. En C11:

Envoyé par C11 6.5.2.4/2

The result of the postfix ++ operator is the value of the operand. As a side effect, the value of the operand object is incremented

**CleeM** · 10/08/2012, 11h39

Bon bin c'est réglé, un gros merci à vous. En effet c'est à cause du malloc et du +33, j'ai dû rajouter quelques caractères par la suite (des doubles quotes), et j'ai tout simplement oublié d'incrémenter ce nombre...
Une erreur très, très bête donc, comme sa m'arrive souvent (trop souvent :/).

Par contre j'ai encore une dernière question, comment sa se fait que mon programme ne plantait pas directement lors du sprintf? Si c'était le cas j'aurais détecter l'erreur bien plus tôt!
Pour moi, insérer des valeurs dans une case mémoire trop petite provoque une SegFault, mais apparemment cette erreur n'arrive que plus tard (quand exactement?) d'où le fait que je n'ai pas compris rapidement d'où venait le problème.

Je passe le topic en résolu mais si vous avez une réponse je suis preneur

screetch · 10/08/2012, 11h45

la memoire "autour" de la chaine appartient quand meme a ton programme, donc tu ne declenches pas une erreur immediate. Tu ecris dans des donnees qui t'appartiennent (enfin a ton programme) donc personne ne rale.

Mais ces donnees ne sont pas celles que tu penses; tu ecris par dessus des donnees utilisees pour autre chose (en l'occurrence je pense que c'est la liste chainee des blocs memoires, mais ca pourrait etre un autre objet que tu as alloue)

des fois, la memoire t'appartient mais n'est pas encore utilisee. Du coup, tout a l'air de fonctionner bien que tu ecrives en dehors de ton objet. Des fois, comme la, tu ecris par dessus un objet deja existant, et lorsque le programme accedera de nouveau a cet objet, on ne sait pas ce qui se passera (c'est le probleme des "overwrite" en memoire comme tu le fais; dans quelques cas, il ne se passe rien, dans le pire des cas, tu ecris sur une memoire qui n'est pas utilisee souvent et ca plante des secondes ou des minutes apres avoir reecrit par dessus un objet).

Plantage du projet lors de l'appel à la commande System

C++

Discussions similaires

Partager

Partager