Segmentation fault lié à un cast

Version imprimable

Bonjour,

Je suis en train de peaufiner un crypteur par courbe elliptique en mettant dans celui-ci un ... crackeur :mrgreen:. C'est un crackage par force brute (de toute façon on peut pas faire mieux :aie:). Pour améliorer la vitesse de crackage j'ai eu l'idée d'utiliser plusieurs threads ce qui distribue les calculs sur les coeurs du processeur (autant que ça tourne à 100%).

Le problème, c'est que ça plante: un bel segmentation fault dans les règles de l'art du crash.

Code:

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
 
template<typename T>
class InfoPackage
{
    public:
 
        InfoPackage(){}
        InfoPackage(Cracker<T>* cracker, User<T>* user, User<T>* connectedUser, int offset, int iterateBy):
         m_cracker(cracker),
         m_user(user),
         m_connectedUser(connectedUser),
         m_offset(offset),
         m_iterateBy(iterateBy)
        {}
 
        Cracker<T>* m_cracker;
        User<T>* m_user;
        User<T>* m_connectedUser;
        int m_offset;
        int m_iterateBy;
};
 
template<typename T>
void* CrackKey(void* infos)
{
    InfoPackage<T> informations = *(static_cast<InfoPackage<T>*>(infos));
    Cracker<T>* cracker = informations.m_cracker;
    std::pair<T,T> point = cracker->m_connections[informations.m_user].m_refPoint;
    std::pair<T,T> researchedPoint = informations.m_user->GetComputedPoint(informations.m_connectedUser);
    EllipticCurve<T> curve = cracker->m_connections[informations.m_user].m_curve;
 
    for(long long i = informations.m_offset;; i+= informations.m_iterateBy)
    {
        cracker->m_mutex.Lock();
        if(cracker->keyA != 0)
        {
            cracker->m_mutex.UnLock();
            break;
        }
 
        if(curve.QuickExponentiation(i, point) == researchedPoint)
        {
            cracker->keyA = i;
            break;
            cracker->m_mutex.UnLock();
            return (void*)0;
        }
    }
}

Ce n'est pas du aux boucles mais aux opérations précédentes.

Voila, si vous pouviez m'aider.
Merci.

05/03/2008, 17h11
Luther13

Aller ,
Je vais m'engager sur ce post qui me semble de haute volée.

InfoPackage<T> devrait avoir un constructeur par recopie à cause de
l'initialisation faite dans le bout de code contenant le static_cast.
Le static_cast, lorsqu'il ne génère pas d'exception, ne renvoi pas de pointeur NULL.
05/03/2008, 18h14
khazna

Je ne comprends pas la nécessité d'un constructeur de copie, car je dois conserver un pointeur sur le "Cracker" et les "User" surveillés. Si vous pouviez me donner des explications (et qu'est-ce qu'il doit faire ce constructeur).

ps: Arf, c'est pas pour moi, mais pour mon grand frère que je fais ça :aie:

second EDIT: après avoir changé le cast dans un autre bout de code (celui gérant les threads win) d'un dynamic_cast vers un static_cast, ça ne plante plus avec le constructeur de copie.

ps ps : C'est normal que mon processeur (un double core) ne fonctionne qu'à 50% et que seulement deux threads soient détectés par win?
06/03/2008, 15h19
Luther13
Citation:

Envoyé par khazna

Je ne comprends pas la nécessité d'un constructeur de copie, car je dois conserver un pointeur sur le "Cracker" et les "User" surveillés. Si vous pouviez me donner des explications (et qu'est-ce qu'il doit faire ce constructeur).

Ce constructeur permettra de s'assurer que les données, en particulier les ponsteurs, sont bien copié. La menace ici est d'éviter que les membres
Code:

1 2 Cracker<T>* m_cracker; User<T>* m_user;
pointent sur un zone de infos qui n'est peut-être pas disponible.

Citation:

Envoyé par khazna

second EDIT: après avoir changé le cast dans un autre bout de code (celui gérant les threads win) d'un dynamic_cast vers un static_cast, ça ne plante plus avec le constructeur de copie.

Bizzard, le dynamic_cast est pourtant plus sûr que le static_cast.
06/03/2008, 15h47
Médinoc

Il est possible qu'en fait, ça fasse un comportement pire que le plantage, si le "plantage" était une exception levée par dynamic_cast<> ou un déréférencement de pointeur nul...