Appel DLL C++ avec le CRL 2.0

Version imprimable

Voir 40 message(s) de cette discussion en une page

22/05/2015, 18h31
AliHome

Appel DLL C++ avec le CRL 2.0
Bonjour à tous,

Je vous explique mon problème :

J'ai une DLL en C++, LibFlac permettant de traiter les fichiers audio FLAC (http://www.rarewares.org/files/lossl...-1.3.1-icl.zip), que j'exploite à l'aide d'une autre librairie que voici :
https://code.google.com/p/practicesharp/

Le problème, c'est qu'en utilisant la DLL "NaudioFLAC" (de practicesharp) sur un projet utilisant le .NET 4.0 et 4.5 par exemple, j'ai une erreur un peu bizarre sur un appel à la DLL C++.
Or, si je change le framework en 3.5, utilisant bien le CLR 2.0 tout fonctionne correctement.

Ma question est, comment forcer l'utilisation du .NET 3.5 (CLR 2.0) juste pour la DLL NAudioFLAC tout en gardant mon projet en .NET 4.0 ?
J'ai trouvé une solution disant de mettre ça dans le fichier app.config :
Code:

1 2 3 <startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/> </startup>
mais ça ne fonctionne pas.

Merci d'avance pour vos réponses.
25/05/2015, 11h41
Médinoc

Citation:

j'ai une erreur un peu bizarre

:bouledecristal:

Je ne sais plus trop quelles sont les difficultés exactes pour les interactions entre DLLs prévues pour différentes versions du framework (ou pire, les DLLs prévues pour interagir avec deux versions différentes d'une même DLL).
Je dirais au pire, si tout le reste échoue, faire du out-of-process avec WCF...
25/05/2015, 14h33
AliHome
Citation:

Envoyé par Médinoc

:bouledecristal:

Je ne sais plus trop quelles sont les difficultés exactes pour les interactions entre DLLs prévues pour différentes versions du framework (ou pire, les DLLs prévues pour interagir avec deux versions différentes d'une même DLL).
Je dirais au pire, si tout le reste échoue, faire du out-of-process avec WCF...

:mouarf: c'est vrai que j'ai pas précisé je pensais pas ça utile, j'imagine que personne ici n'a déjà utilisé cette librairie, mais voici l'erreur :

"FLAC: Could not process single!"

Sur cette fonction à priori :
Code:

1 2 [DllImport(DLLName, CallingConvention = CallingConvention.Cdecl)] public static extern bool FLAC__stream_decoder_process_single(IntPtr context);
Pour la solution WCF c'est pas envisageable malheureusement, étant donné la perte de performance...
25/05/2015, 15h01
Médinoc

Ce message d'erreur, est-il visible dans le code qui appelle cette fonction, ou bien vient-il de la fonction elle-même?

Non à vrai dire ce message n'est pas d'une grande utilité, je vous montre d'où il provient :
Code:

1 2 3 FLACCheck( LibFLACSharp.FLAC__stream_decoder_process_single(m_decoderContext), "process single");
Code:

1 2 3 4 5 private void FLACCheck(bool result, string operation) { if (!result) throw new ApplicationException(string.Format("FLAC: Could not {0}!", operation)); }
Donc ça ne vient pas de la DLL C LibFlac.

D'ailleurs quand on regarde la doc, c'est pas détaillé du tout.

https://xiph.org/flac/api/group__fla...122cf7f987f856

Citation:

Return values
FLAC__bool false if any fatal read, write, or memory allocation error occurred (meaning decoding must stop), else true; for more information about the decoder, check the decoder state with FLAC__stream_decoder_get_state().

25/05/2015, 16h29
AliHome

Peut-être qu'il faut aussi se poser la question de savoir pourquoi l'appel à cette fonction marche avec le CLR 2.0, et pas avec le 4.0 ? J'ai toujours lu partout que le CLR 4.0 était rétrocompatible avec le 2.0...
25/05/2015, 16h50
bacelar

Citation:

j'ai une erreur un peu bizarre sur un appel à la DLL C++.

Pouvez-vous être un peu plus précis ?
25/05/2015, 16h52
AliHome

Citation:

Envoyé par bacelar

Pouvez-vous être un peu plus précis ?

Oui je la décris juste en dessous dans un de mes messages
25/05/2015, 23h26
bacelar

Oups, quelques messages de loupés. :aie:
Comme il s'agit d'Open-Source, le débugging dans les sources de la bibliothèque pourrait nous donner de précieux complément d'informations, non ?
27/05/2015, 19h01
AliHome

Citation:

Envoyé par bacelar

Oups, quelques messages de loupés. :aie:
Comme il s'agit d'Open-Source, le débugging dans les sources de la bibliothèque pourrait nous donner de précieux complément d'informations, non ?

Oui tout à fait, j'essaye depuis plusieurs jours de trouver l'origine de l'erreur, en vain.

Voici les sources si quelqu'un se sent de déboguer :

https://github.com/xiph/flac
Il faut à priori utiliser nasm pour compiler, et également une lib d'ici :
https://github.com/xiph/ogg

Je pense que le problème doit venir du callback (stream_decoder.c > ligne 2976 ?) entre la DLL C et le client (.NET), sauf que je ne vois pas où ça capote.

Je vous met ici les bouts de code concernés, peut-être que certains ici seraient en mesure de dire si le CLR 4.0 l'interprète différemment du 2.0 etc

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
        private void FLAC_WriteCallback(IntPtr context, IntPtr frame, IntPtr buffer, IntPtr clientData)
        {
            // Read the FLAC Frame into a memory samples buffer (m_flacSamples)
            LibFLACSharp.FlacFrame flacFrame = (LibFLACSharp.FlacFrame)Marshal.PtrToStructure(frame, typeof(LibFLACSharp.FlacFrame));
 
            if (m_flacSamples == null)
            {
                // First time - Create Flac sample buffer
                m_samplesPerChannel = flacFrame.Header.BlockSize;
                m_flacSamples = new int[m_samplesPerChannel * m_flacStreamInfo.Channels];
                m_flacSampleIndex = 0;
            }
 
            // Iterate on all channels, copy the unmanaged channel bits (samples) to the a managed samples array
            for (int inputChannel = 0; inputChannel < m_flacStreamInfo.Channels; inputChannel++)
            {
                // Get pointer to channel bits, for the current channel
                IntPtr pChannelBits = Marshal.ReadIntPtr(buffer, inputChannel * IntPtr.Size);
 
                // Copy the unmanaged bits to managed memory
                Marshal.Copy(pChannelBits, m_flacSamples, inputChannel * m_samplesPerChannel, m_samplesPerChannel);
            }
 
            lock (m_repositionLock)
            {
                // Keep the current sample number for reporting purposes (See: Position property of FlacFileReader)
                m_lastSampleNumber = flacFrame.Header.FrameOrSampleNumber;
 
                if (m_repositionRequested)
                {
                    m_repositionRequested = false;
                    FLACCheck(LibFLACSharp.FLAC__stream_decoder_seek_absolute(m_decoderContext, m_flacReposition), "Could not seek absolute: " + m_flacReposition);
                }
            }
        }

Dans le constructeur de la classe on a ça :

Code:

m_writeCallback = new LibFLACSharp.Decoder_WriteCallback(FLAC_WriteCallback);

La déclaration :

Code:

private LibFLACSharp.Decoder_WriteCallback m_writeCallback;

Le delegate :

Code:

1
2
[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
public delegate void Decoder_WriteCallback(IntPtr context, IntPtr frame, IntPtr buffer, IntPtr userData);

Voilà pour le callback du coté de la classe C#. Après recherche j'ai pu constater que le FLAC_WriteCallback ne retourne pas ce qu'il devrait, à savoir "FLAC__STREAM_DECODER_WRITE_STATUS_CONTINUE", comme montré ici dans le code en C de la librairie FLAC :

Code:

if (write_audio_frame_to_client_(decoder, &decoder->private_->frame, (const FLAC__int32 * const *)decoder->private_->output) != FLAC__STREAM_DECODER_WRITE_STATUS_CONTINUE) return false;

J'ai vérifié en testant, en .NET 3.5 on a bien FLAC__STREAM_DECODER_WRITE_STATUS_CONTINUE, et en 4.0 on a des chiffres aléatoires (valeur d'un pointeur ?). Le problème est donc directement lié à la valeur retournée par le callback, sauf que je ne vois pas où c'est géré en fait :?

Merci pour votre aide !

28/05/2015, 17h22
AliHome

Veuillez m'excuser pour tout les messages, j'ai oublié de préciser une dernière info. La partie du code dans "write_audio_frame_to_client_" ou on voit bien que ça retourne le résultat du callback :

Code:

return decoder->private_->write_callback(decoder, frame, buffer, decoder->private_->client_data);

Promis j'arrête maintenant :mrgreen:
29/05/2015, 14h21
bacelar

Pas de soucis pour les gros repost.
Juste un EDIT du message pour éviter les petits repost. ;)

J'ai du mal à voir d'où sort la valeur de retour de "FLAC_WriteCallback" vu que ça retourne un void.

Il y aurait pas un souci dans la définition du delegate Decoder_WriteCallback ?

Si je me rappelle bien des conventions d'appel C sous Intel, il récupère la valeur de retour de la fonction en haut de la pile, donc, pour moi, un truc "aléatoire".

C'est quoi la signature de la fonction "write_audio_frame_to_client_" ?

Citation:

J'ai vérifié en testant, en .NET 3.5 on a bien FLAC__STREAM_DECODER_WRITE_STATUS_CONTINUE

C'est peut-être tombé en marche en .NET 3.5.
29/05/2015, 14h45
AliHome

Oui en fait je me suis rendu compte qu'on pouvait éditer après coup :mrgreen:

Voilà c'est bien ça qui me chiffonne, c'est un void, donc je ne comprend pas comment la valeur est renvoyée en fait, Et étant donné que ça fonctionne en .NET 3.5...

La déclaration :

Code:

FLAC__StreamDecoderWriteStatus write_audio_frame_to_client_(FLAC__StreamDecoder *decoder, const FLAC__Frame *frame, const FLAC__int32 * const buffer[])

Citation:

C'est peut-être tombé en marche en .NET 3.5.

Qu'entendez vous par là ?
29/05/2015, 19h56
bacelar
"FLAC__StreamDecoderWriteStatus" je suppose que c'est un int ou un truc du genre ?

Il y a clairement un problème dans
Code:

1 2 [UnmanagedFunctionPointer(CallingConvention.Cdecl)] public delegate void Decoder_WriteCallback(IntPtr context, IntPtr frame, IntPtr buffer, IntPtr userData);
Ça sort d'où ?
Qui en est l'auteur ?

Le code natif veut 3 paramètres (passé dans la pile en convention C standard, avec ceux à droites empilé en premier) et un retour en code erreur (int).
Le code managé veut 4 paramètres et ne renvoie rien, ça sent pas bon.

Citation:

Qu'entendez vous par là ? (tombé en marche en .NET 3.5. )

C'est que le fait que de l'extérieur, on ne voit pas de bugs ne veut pas dire qu'il n'y a pas de bug latent.

Il est fort probable que la version 4 du framework face plus de contrôle et de cloisonnement, pour des problèmes de sécurité d'exécution, par exemple, que la version 3.5.

Pour moi, on est sur la trace d'un bug latent, et il a toujours été là, tapis dans l'ombre. :aie:

Alors pour le code C# ça vient de ce lien que j'ai mis au début :
https://code.google.com/p/practicesharp/

Pour la déclaration :
Code:

1 2 3 4 5 6 7 8 9 10 11 /** Return values for the FLAC__StreamDecoder write callback. */ typedef enum { FLAC__STREAM_DECODER_WRITE_STATUS_CONTINUE, /**< The write was OK and decoding can continue. */ FLAC__STREAM_DECODER_WRITE_STATUS_ABORT /**< An unrecoverable error occurred. The decoder will return from the process call. */ } FLAC__StreamDecoderWriteStatus;
Et en effet où est passé le 4ème paramètre, mystère, surtout que dans le header on a ça :

Code:

typedef FLAC__StreamDecoderWriteStatus (*FLAC__StreamDecoderWriteCallback)(const FLAC__StreamDecoder *decoder, const FLAC__Frame *frame, const FLAC__int32 * const buffer[], void *client_data);

Tout le code C vient de la fondation Xiph qui développent le format FLAC (j'ai aussi donné le lien git de leurs sources).

Citation:

Pour moi, on est sur la trace d'un bug latent, et il a toujours été là, tapis dans l'ombre. :aie:

Vous pensez que le problème viendrait de quel coté, la librairie de Xiph en C ou le C# ?

Merci à vous

31/05/2015, 23h42
bacelar

Je ne suis pas un spécialiste du P/Invoke, j'ai toujours tendance à mettre une couche C++/CLI entre le code managé et le code natif.
Pouvez-vous vérifier avec un outils comme celui ci-après, si la signature C# correspond ?
http://blogs.msdn.com/b/bclteam/arch...an-patten.aspx

Je serais assez étonné que cela corresponde.

A vrai dire moi non plus, et j'ai tenté d'ouvrir la dll avec votre outil ça ne fonctionne pas j'ai une erreur, à moins que je n'ai pas bien compris son utilisation.

EDIT : j'ai retenté de deboguer, et bizarrement cette fois ci l'espion sur Visual Studio me donne la valeur correspondant au retour, et surprise ce n'est pas aléatoire mais :

Code:

FLAC__STREAM_DECODER_WRITE_STATUS_ABORT | 2970270 (2970271)

Pour rappel :

Code:

1
2
3
4
5
6
7
8
9
10
11
/** Return values for the FLAC__StreamDecoder write callback.
 */
typedef enum {
 
	FLAC__STREAM_DECODER_WRITE_STATUS_CONTINUE,
	/**< The write was OK and decoding can continue. */
 
	FLAC__STREAM_DECODER_WRITE_STATUS_ABORT
	/**< An unrecoverable error occurred.  The decoder will return from the process call. */
 
} FLAC__StreamDecoderWriteStatus;

EDIT2 : complément d'informations

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
/// <summary>Constructor - Supports opening a FLAC file</summary>
        public FLACFileReader(string flacFileName)
        {
            Console.WriteLine("FLACFileReader: " + flacFileName);
            // Open the flac file for reading through a binary reader
            m_stream = File.OpenRead(flacFileName);
            m_reader = new BinaryReader(m_stream);
            // Create the FLAC decoder
            m_decoderContext = LibFLACSharp.FLAC__stream_decoder_new();
 
            if (m_decoderContext == IntPtr.Zero)
                throw new ApplicationException("FLAC: Could not initialize stream decoder!");
 
            // Create call back delegates
            m_writeCallback = new LibFLACSharp.Decoder_WriteCallback(FLAC_WriteCallback);
            m_metadataCallback = new LibFLACSharp.Decoder_MetadataCallback(FLAC_MetadataCallback);
            m_errorCallback = new LibFLACSharp.Decoder_ErrorCallback(FLAC_ErrorCallback);
 
            // Initialize the FLAC decoder
            if (LibFLACSharp.FLAC__stream_decoder_init_file(m_decoderContext,
                                               flacFileName, m_writeCallback, m_metadataCallback, m_errorCallback,
                                               IntPtr.Zero) != 0)
                throw new ApplicationException("FLAC: Could not open stream for reading!");
 
            // Process the meta-data (but not the audio frames) so we can prepare the NAudio wave format
            FLACCheck(
                LibFLACSharp.FLAC__stream_decoder_process_until_end_of_metadata(m_decoderContext),
                "Could not process until end of metadata");
 
            // Initialize NAudio wave format
            m_waveFormat = new WaveFormat(m_flacStreamInfo.SampleRate, m_flacStreamInfo.BitsPerSample, m_flacStreamInfo.Channels);
 
            Console.WriteLine("Total FLAC Samples: {0}", LibFLACSharp.FLAC__stream_decoder_get_total_samples(m_decoderContext));
        }

Code:

1
2
[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
        public delegate void Decoder_WriteCallback(IntPtr context, IntPtr frame, IntPtr buffer, IntPtr userData);

Code:

1
2
[DllImport(DLLName, CallingConvention = CallingConvention.Cdecl)]
        public static extern int FLAC__stream_decoder_init_file(IntPtr context, string filename, Decoder_WriteCallback write, Decoder_MetadataCallback metadata, Decoder_ErrorCallback error, IntPtr userData);

Après avoir testé, je me suis rendu compte que le problème viendrait de cette partie :
Code:

1 2 3 4 5 6 7 8 9 10 11 lock (m_repositionLock) { // Keep the current sample number for reporting purposes (See: Position property of FlacFileReader) m_lastSampleNumber = flacFrame.Header.FrameOrSampleNumber; if (m_repositionRequested) { m_repositionRequested = false; FLACCheck(LibFLACSharp.FLAC__stream_decoder_seek_absolute(m_decoderContext, m_flacReposition), "Could not seek absolute: " + m_flacReposition); } }
Il y aurait-il une différence entre le CLR 2.0 et 4.0 dans la façon de gérer le lock qui pourrait induire un problème ? Je ne suis pas un spécialiste du multi threading, du coup j'ai du mal à isoler le problème. En tout cas je sens que je me rapproche du problème, ce qui est d'ailleurs plus cohérent car il ne se produit qu'en changeant le .NET Framework utilisé.

03/06/2015, 17h03
Médinoc

Je ne crois pas qu'il y ait vraiment de différence de ce côté-ci. Es-tu sûr que le lock commence et finit bien là où il faut?
Et qu'en est-il des autres locks sur le même objet?

Voir 40 message(s) de cette discussion en une page