GNOME.org
 

Re: [Ekiga-list] Newbie, help: Account mgmt problems

I've isolated the problem. In a fresh install, right after the configuration wizard, clear the "Authentication User" field for the Ekiga account. After this an exit + restart corrupts the Ekiga account data.
Trying to sort things out, I ran ekiga under valgrind. There is a lot of "Conditional jump or move depends on uninitialised value(s)"; I presume these are irrelevant. Besides these, Ekiga runs clean when the "Authentication User" field is non-empty.
However, the following two errors occurs iff the "Authentication User" field is empty i. e., when the data corruption occurs. 

Signing off,

--alec
==27886== Syscall param socketcall.sendto(msg) points to uninitialised byte(s) 
==27886==    at 0x3906C0E65C: (within /lib64/libpthread-2.9.so)
==27886== by 0x3A68F4230B: PSocket::os_sendto(void const*, int, int, sockaddr*, int) (in /usr/lib64/libpt.so.2.4.4) ==27886== by 0x3A68F66A08: PIPDatagramSocket::WriteTo(void const*, int, PIPSocket::Address const&, unsigned short) (in /usr/lib64/libpt.so.2.4.4) ==27886== by 0x3A68F6CDC4: PMonitoredSockets::WriteToSocket(void const*, int, PIPSocket::Address const&, unsigned short, PMonitoredSockets::SocketInfo const&, int&) (in /usr/lib64/libpt.so.2.4.4) ==27886== by 0x3A68F6CEF3: PMonitoredSocketBundle::WriteToBundle(void const*, int, PIPSocket::Address const&, unsigned short, PString const&, int&) (in /usr/lib64/libpt.so.2.4.4) ==27886== by 0x3A68F6C91E: PMonitoredSocketChannel::Write(void const*, int) (in /usr/lib64/libpt.so.2.4.4) ==27886== by 0x3A68F46327: PIndirectChannel::Write(void const*, int) (in /usr/lib64/libpt.so.2.4.4) ==27886== by 0x3A68F46911: PChannel::WriteString(PString const&) (in /usr/lib64/libpt.so.2.4.4) ==27886== by 0x3A69B9B2AF: SIP_PDU::Write(OpalTransport&, OpalTransportAddress const&, PString const&) (in /usr/lib64/libopal.so.3.4-beta4) ==27886== by 0x3A69BA0C43: SIPTransaction::Start() (in /usr/lib64/libopal.so.3.4-beta4) ==27886== by 0x3A69BB6153: SIPHandler::WriteSIPHandler(OpalTransport&) (in /usr/lib64/libopal.so.3.4-beta4) ==27886== by 0x3A69BB62C8: SIPHandler::WriteSIPHandler(OpalTransport&, void*) (in /usr/lib64/libopal.so.3.4-beta4) 

==27886== Use of uninitialised value of size 8
==27886==    at 0x390EC7F0B3: (within /usr/lib64/libstdc++.so.6.0.10)
==27886== by 0x390EC85BC6: std::ostreambuf_iterator<char, std::char_traits<char> > std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::_M_insert_int<unsigned long>(std::ostreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, char, unsigned long) const (in /usr/lib64/libstdc++.so.6.0.10) ==27886== by 0x390EC85DF6: std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::do_put(std::ostreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, char, unsigned long) const (in /usr/lib64/libstdc++.so.6.0.10) ==27886== by 0x390EC98D5B: std::ostream& std::ostream::_M_insert<unsigned long>(unsigned long) (in /usr/lib64/libstdc++.so.6.0.10) 
==27886==    by 0x4BD1FF: Opal::Account::edit() (in /usr/bin/ekiga)
==27886== by 0x390AC0B7DC: g_closure_invoke (in /lib64/libgobject-2.0.so.0.1800.3) 
==27886==    by 0x390AC214BC: (within /lib64/libgobject-2.0.so.0.1800.3)
==27886== by 0x390AC22B67: g_signal_emit_valist (in /lib64/libgobject-2.0.so.0.1800.3) ==27886== by 0x390AC23092: g_signal_emit (in /lib64/libgobject-2.0.so.0.1800.3) ==27886== by 0x3569831ACA: gtk_widget_activate (in /usr/lib64/libgtk-x11-2.0.so.0.1400.5) ==27886== by 0x356973658C: gtk_menu_shell_activate_item (in /usr/lib64/libgtk-x11-2.0.so.0.1400.5) 
==27886==    by 0x3569737FD4: (within /usr/lib64/libgtk-x11-2.0.so.0.1400.5)



chaitanya mehandru wrote:

If you can do this,it may help to resolve:
 - ekiga-config-tool --clean
 - ekiga-config-tool --fix-permissions
 - ekiga-config-tool --clean-schemas
 - ekiga-config-tool --install-schemas
--Disable the STUN support while running the configuration wizard; --Make 2 new sip accounts and while running the configuration wizard,register with one of the new users. --Add a sip account to ekiga with authentication user being the same as user name. If this doesn't help, probably there might be some library to be installed to keep the values in the respective fields. I have been able to run Ekiga 3.0.2 with H264 enabled on Ubuntu 8.10,8.04 without any similar issues.
On Fri, Jan 30, 2009 at 5:08 PM, Alec Leamas <leamas alec gmail com <mailto:leamas alec gmail com>> wrote: 

    Thanks for your reply!

    First of all I should add that I'm on Fedora/X86_64.

    Did the ekiga-config-tool thing. After a reinstall, and disabling
    the stun server,  there is only two accounts: my ekiga account and
    an account at sip.mysecretary.net <http://sip.mysecretary.net>.
    Situation after a Chat | Quit + restart:

    - The data for both accounts is corrupted (password moved to
     "Authentication User",  Password + Timeout set to random values).

    - The account is presented as "Registered" despite that it isn't
    logged in at the
     server  (I can verify this on the server side  for the
    mysecretary account).

    - Invoking the Account | Edit Account dialog with correct,
    unchanged data
     effectively toggles the account between Registered and Unregistered.

    - With data OK, successfully logged in to mysecretary.net
    <http://mysecretary.net> and making
     a Chat | Quit the server does not understand that the client is
    disconnected (still
     presented as present/logged in by server). Possibly a server issue?

    - The server eventually understands that the client has
    disconnected after the
     timeout specified fot the account.

    I have a feeling that there are at least two things here: data
    corruption and presence mgmt. But, I'm a newbie and should thus
    not have any feelings ;-)


    Damien Sandras wrote:

        Le jeudi 29 janvier 2009 à 13:45 +0100, Alec Leamas a écrit :

            Oops, forgot...  Ekiga 3.0.2 on Fedora 10, updated as of
            today. The install is a clean install from Fedora's
            repositories.



        Try purging the configuration totally (ekiga-config-tool
        --clean) and
        start from scratch. There is no known bug corrupting the
        accounts data.


    _______________________________________________
    ekiga-list mailing list
    ekiga-list gnome org <mailto:ekiga-list gnome org>
    http://mail.gnome.org/mailman/listinfo/ekiga-list


------------------------------------------------------------------------

_______________________________________________
ekiga-list mailing list
ekiga-list gnome org
http://mail.gnome.org/mailman/listinfo/ekiga-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]