Re: valgrind warnings [Re: Emacs bzr memory footprint]

[Dan Nicolaescu]

Dan Nicolaescu <address@hidden> writes:

> Eli Zaretskii <address@hidden> writes:
>
>> So I imagine one needs to do this (100% untested):
>>
>>   ./temacs -l loadup
>>   M-x load-file RET ~/.emacs RET
>
> Actually
>  ./temacs 
>
> is enough.
>
> On Fedora 15 with valgrind-3.6.1 it is possible to run 
>
> valgrind ./temacs
>
> Valgrind produces these warnings, maybe some of them are interesting:
>
> ==30382== Conditional jump or move depends on uninitialised value(s)
> ==30382==    at 0x499251: coding_set_destination (coding.c:1046)
> ==30382==    by 0x4B477A: decode_coding (coding.c:7022)
> ==30382==    by 0x4B7317: decode_coding_object (coding.c:7671)
> ==30382==    by 0x63610F: Fcall_process (callproc.c:813)
> ==30382==    by 0x5D6C07: Ffuncall (eval.c:2956)
> ==30382==    by 0x5D5ECA: Fapply (eval.c:2479)
> ==30382==    by 0x5D6C07: Ffuncall (eval.c:2956)
> ==30382==    by 0x622C5B: exec_byte_code (bytecode.c:785)
> ==30382==    by 0x5D77BA: funcall_lambda (eval.c:3205)
> ==30382==    by 0x5D6F4C: Ffuncall (eval.c:3023)
> ==30382==    by 0x622C5B: exec_byte_code (bytecode.c:785)
> ==30382==    by 0x5D77BA: funcall_lambda (eval.c:3205)

This looks like setup_coding_system (or whatever else initializes struct
coding_system) does not initialize the src_pos field.

>
> ==30382== Conditional jump or move depends on uninitialised value(s)
> ==30382==    at 0x6302A9: send_process (process.c:5398)
> ==30382==    by 0x630DC8: Fprocess_send_string (process.c:5648)
> ==30382==    by 0x5D6D61: Ffuncall (eval.c:2977)
> ==30382==    by 0x622C5B: exec_byte_code (bytecode.c:785)
> ==30382==    by 0x5D77BA: funcall_lambda (eval.c:3205)
> ==30382==    by 0x5D6F4C: Ffuncall (eval.c:3023)
> ==30382==    by 0x622C5B: exec_byte_code (bytecode.c:785)
> ==30382==    by 0x5D77BA: funcall_lambda (eval.c:3205)
> ==30382==    by 0x5D6F4C: Ffuncall (eval.c:3023)
> ==30382==    by 0x622C5B: exec_byte_code (bytecode.c:785)
> ==30382==    by 0x5D77BA: funcall_lambda (eval.c:3205)
> ==30382==    by 0x5D6F4C: Ffuncall (eval.c:3023)

similarly the struct coding_system.src_multibyte needs to be
initialized.


> ==30382== Conditional jump or move depends on uninitialised value(s)
> ==30382==    at 0x636022: Fcall_process (callproc.c:799)
> ==30382==    by 0x5D6C07: Ffuncall (eval.c:2956)
> ==30382==    by 0x5D5ABB: Fapply (eval.c:2422)
> ==30382==    by 0x5D6C07: Ffuncall (eval.c:2956)
> ==30382==    by 0x622C5B: exec_byte_code (bytecode.c:785)
> ==30382==    by 0x5D77BA: funcall_lambda (eval.c:3205)
> ==30382==    by 0x5D6F4C: Ffuncall (eval.c:3023)
> ==30382==    by 0x5D5ABB: Fapply (eval.c:2422)
> ==30382==    by 0x5D6C07: Ffuncall (eval.c:2956)
> ==30382==    by 0x622C5B: exec_byte_code (bytecode.c:785)
> ==30382==    by 0x5D77BA: funcall_lambda (eval.c:3205)
> ==30382==    by 0x5D6F4C: Ffuncall (eval.c:3023)

similarly the struct coding_system.dst_multibyte needs to be
initialized.


> ==30382== Use of uninitialised value of size 8
> ==30382==    at 0x5B7000: mark_object (alloc.c:5674)
> ==30382==    by 0x5B4C9B: mark_maybe_object (alloc.c:4152)
> ==30382==    by 0x5B4FE6: mark_memory (alloc.c:4274)
> ==30382==    by 0x5B507E: mark_stack (alloc.c:4532)
> ==30382==    by 0x5B5F48: Fgarbage_collect (alloc.c:5119)
> ==30382==    by 0x5D69F0: Ffuncall (eval.c:2911)
> ==30382==    by 0x5D64CA: call2 (eval.c:2758)
> ==30382==    by 0x5809AA: Finsert_file_contents (fileio.c:4144)
> ==30382==    by 0x5D6E00: Ffuncall (eval.c:2990)
> ==30382==    by 0x622C5B: exec_byte_code (bytecode.c:785)
> ==30382==    by 0x5D77BA: funcall_lambda (eval.c:3205)
> ==30382==    by 0x5D6F4C: Ffuncall (eval.c:3023)

It would be interesting to know if the gc warnings are relevant...