VLC Crashes after opening AudioCD and trying to fetch CDDB info over the network- but only on Windows OSes

Can you run in gdb this issue and provide a stacktrace? That would help a lot.

Yes, of course, I was going to do that today!

Really, by now, I suspect that is a "SEG fault" caused by a BOOL variable not properly initiallized in the cddb_conn_s structure ( that is not part of VLC source code, but part of libcddb headers: "<cddb/cddb_conn_ni.h>", but the member variable is really defined in <netinet/in.h> ).

Anyway, the name of the member variable is p_cddb->cache_read and its value should be FALSE ( = 0 ) before calling function cddb_query( p_cddb, p_disc ) , but for some reason as far as I could debug, in Windows platforms it gets random integer values instead ( which makes it seem TRUE ) although in libcddb source code, it is clearly initialized as FALSE when calling funtion cddb_disc_new()...

So, I have found a simple workaround to avoid the crash, to add this code line in in modules/access/cdda.c :

p_cddb->cache_read=FALSE;

const int i_matches = cddb_query( p_cddb, p_disc );

Anyway, tomorrow I will post the gdb backtrace log !!!

You, sir, rock!

People have been complaining about that on and off, and I was never able to reproduce it.

Where do you add the line to fix it?

And which of the 2 lines?

Thanks!

The existing call to function cddb_query() is located in current line 663 of modules/access/cdda.c source code.

So we should place the following initialization before that call:

p_cddb->cache_read=FALSE;

In fact, it is not that simple... Because when you try to compile, in order for the compiler to dereference that structure, you need to include a libcddb header that is not currently bundled with mingw64 contribs :

 #include <cddb/cddb_conn_ni.h>     // here the struct cddb_conn_s is defined

So the quickest solution is to copy ALL libcddb headers ( from /usr/include/cddb/, if you have previously installed libcddb in your linux distro ) to the cddb contrib include dir:

$HOME/vlc/contrib/i686-w64-mingw32/include/cddb/

This worked ok for crosscompiling against latest i686-w64-mingw32 contrib, but after adding that line, if you try to build VLC for your native linux, then the compiler complains again, so you also need to include this inside cdda.c :

 #include <netinet/in.h>   // here the member variable cache_read is actually defined

I am doing some more testing, but until now it seems the crash had disappered after this modifications :) ...

assigned to @jbk

added Component::Build system: Contribs label

changed milestone to %2.2.0

commit 86cb5795 Author: Jean-Baptiste Kempf jb@videolan.org Date: Fri Jan 2 15:56:00 2015 +0100

Contrib: fix crash in CDDB on Windows

Close [#13465](https://code.videolan.org/videolan/vlc/-/issues/13465)

Original author: jb@videolan.org

added Status::fixed label

closed

Here is the backtrace from gdb, though it does not seem very helpfull to me...

D:\vlc-3.0.0-git-20150102-0003-win32-debug\vlc-3.0.0-git-201501
02-0003>gdb
GNU gdb (GDB) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".

This binary was built by Equation Solution <http://www.Equation.com>.
(gdb) target exec vlc
(gdb) run
Starting program: D:\Fede\JDownloader\vlc-3.0.0-git-20150102-0003-win32-debug\vl
c-3.0.0-git-20150102-0003\vlc.exe
[New Thread 324.0x980]
[New Thread 324.0x624]
[New Thread 324.0xbe0]
[New Thread 324.0xa98]
warning: core libvlc: Running vlc with the default interface. Use 'cvlc' to use
vlc without interface.

[New Thread 324.0xa4c]
[New Thread 324.0xe38]
[New Thread 324.0x13e4]
warning: setGeometry: Unable to set geometry 0x0+192+144 on QWidgetWindow/'Video
WidgetClassWindow'. Resulting geometry:  115x0+192+144 (frame: 4, 30, 4, 4, cust
om margin: 0, 0, 0, 0, minimum size: 0x0, maximum size: 16777215x16777215).

[New Thread 324.0xdfc]
[New Thread 324.0xe94]
[New Thread 324.0x1358]
[Thread 324.0xe94 exited with code 0]
[New Thread 324.0x254]
[New Thread 324.0x125c]
[New Thread 324.0x4e4]
[Thread 324.0x125c exited with code 0]
[Thread 324.0x1358 exited with code 0]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 324.0x254]
0x7c91100b in ntdll!RtlEnterCriticalSection ()
   from C:\WINDOWS\system32\ntdll.dll
(gdb) bt
[#0](https://code.videolan.org/videolan/vlc/-/issues/0)  0x7c91100b in ntdll!RtlEnterCriticalSection ()
   from C:\WINDOWS\system32\ntdll.dll
[#1](https://code.videolan.org/videolan/vlc/-/issues/1)  0x77c0b90d in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll
[#2](https://code.videolan.org/videolan/vlc/-/issues/2)  0x77c10bdb in msvcrt!fgets () from C:\WINDOWS\system32\msvcrt.dll
[#3](https://code.videolan.org/videolan/vlc/-/issues/3)  0x00000000 in ?? ()
(gdb) quit
A debugging session is active.

        Inferior 1 [process 324] will be killed.

Quit anyway? (y or n) y

Two important points to remark:

-- Suspiciously, this bug only appears when Windows have come back from Hibernate ( tested in WinXP and win7 ), and until now I could never reproduce it if I have just started Windows from a clean boot ( no hibernation ).

-- As I said earlier, the bug disappear if you replace the original file libcdda_plugin.dll ( inside your-vlc-install-dir\plugins\access\ ) with a re-compiled one, after adding the line p_cddb->cache_read=FALSE; that forces the variable initialization before calling cddb_query(), as explained before.

Also remark that, in theory, this initializition should not be needed at all! Because the member variable "cache_read" ( from structure "p_cddb", of typedef cddb_conn_s ) should have already been initialized by an existing prior call to "cddb_disc_new()".

Now The only thing left for testing is to hibernate my Linux distro and see if the bug appears there too! ( which I dont think any likely, ja! )

I have seen the GIT changes committed, so I will wait for the next nightly build and try to reproduce the bug with it... Regards!

It will need contrib rebuild, so might not be in next nightly though...

Ok, thanks... That testing will have to wait then...

Just to complete the bt info above:

If my earlier research was right, the call to msvcrt!fgets() which appears in backtrace corresponds to the next piece of souce code in libcddb ( http://sourcecodebrowser.com/libcddb/1.3.2/cddb__cmd_8c_source.html#l00356 ) :

char * cddb_read_line( cddb_conn_t * c )	
{
    char *s;

    cddb_log_debug("cddb_read_line()");
    /* read line, possibly returning NULL */
    if (c->cache_read) {
        s = fgets(c->line, c->buf_size, cddb_cache_file(c));
        } else {
        s = sock_fgets(c->line, c->buf_size, c);
        }  
      ....

So the wrong value of "cache_read" alters the expected flow of execution and arise an unhandled exepction wich ends up in a SEG Fault. But just guessing...

VLC Crashes after opening AudioCD and trying to fetch CDDB info over the network- but only on Windows OSes

Child items 0

Activity