*scanf %a, patches... (was: Re: get a segmentation fault when starting vdr (backtrace included))

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



In article <50BA09CC.2040104@xxxxxxxxxxxxxx> you write:
>Am 30.11.2012 11:32, schrieb Gerald Dachs:
>> Am 2012-11-30 10:17, schrieb Lars Hanisch:
>>>  Looks like the pointer returned by sscanf is not valid:
>>>
>>> 32: bool tComponent::FromString(const char *s)
>>> 33: {
>>> 34:   unsigned int Stream, Type;
>>> 35:   int n = sscanf(s, "%X %02X %7s %a[^\n]", &Stream, &Type,
>>> language, &description); // 7 = MAXLANGCODE2 - 1
>>> 36:   if (n != 4 || isempty(description)) {
>>> 37:      free(description);
>>> 38:      description = NULL;
>>> 39:      }
>>> 40:   stream = Stream;
>>> 41:   type = Type;
>>> 42:   return n >= 3;
>>> 43: }
>> 
>> From man sscanf:
>> 
>>        The GNU C library supports a nonstandard extension that causes the library to
>>        dynamically allocate a string of sufficient size for input strings for the %s
>>        and %a[range] conversion specifiers.
>> 
>> This is the reason why it doesn't work with ulibc.
>
> Then there should be a malloc or something similiar for description:
>
>32: bool tComponent::FromString(const char *s)
>33: {
>34:   unsigned int Stream, Type;
>      description = malloc(strlen(s));
>      description[0] = 0;
>35:   int n = sscanf(s, "%X %02X %7s %a[^\n]", &Stream, &Type, language, &description); // 7 = MAXLANGCODE2 - 1
>36:   if (n != 4 || isempty(description)) {
>37:      free(description);
>38:      description = NULL;
>39:      }
>40:   stream = Stream;
>41:   type = Type;
>42:   return n >= 3;
>43: }
>
> A check for description != NULL before the free call is not needed.
>
> But this is not the only place in the vdr code, where %a is used...
>
Btw FreeBSD has the same problem (no *scanf %a in libc), so you
could try taking the FreeBSD patches and replacing

	#ifdef __FreeBSD__

by

	#if defined(__FreeBSD__) || defined(__UCLIBC__)

in those parts handling %a here:

	http://svnweb.freebsd.org/ports/head/multimedia/vdr/files/patch-vdr-1.7.28_FreeBSD?revision=300896&view=markup

 A few plugins are affected too: (of those we have in FreeBSD ports)

eepg:

	http://svnweb.freebsd.org/ports/head/multimedia/vdr-plugin-eepg/files/patch-eepg.c?revision=300896&view=markup

infosatepg:

	http://svnweb.freebsd.org/ports/head/multimedia/vdr-plugin-infosatepg/files/patch-process.cpp?view=markup

ttxtsubs:

	http://svnweb.freebsd.org/ports/head/multimedia/vdr-plugin-ttxtsubs/files/patch-ttxtsubschannelsettings.c?revision=300896&view=markup

 HTH, :)
	Juergen

PS:  I think I never sent the FreeBSD patches to Klaus the last few
times I updated them, atm FreeBSD ports is behind again (still at
vdr 1.7.29), when I get around catching up to the latest version I
can send the updated patches if you are interested, Klaus?  A few
more 1.7.29 patches are in here:

	http://svnweb.freebsd.org/ports/head/multimedia/vdr/files/

(I think I did send FreeBSD patches to those plugin maintainers
that may still be active some time ago, haven't heard back from
many tho.)

_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux