http://bugzilla.suse.com/show_bug.cgi?id=1020028 http://bugzilla.suse.com/show_bug.cgi?id=1020028#c3 --- Comment #3 from Jonathan Kang --- I've been spending quit some time to investigate this bug, and make some progress these days. By watching canary word(a mechanism used to protect stack smashing) using gdb to detect where the stack smashing happend, I got the following backtrace: ------

Thread 5 "PK-Backend" hit Hardware watchpoint 2: *0xb31ce1fc

Old value = 399388928 New value = 0 zypp::filesystem::PathInfo::PathInfo (this=<optimized out>, path=<optimized out>, initial=<optimized out>) at /usr/src/debug/libzypp-16.4.3/zypp/PathInfo.cc:172 172 operator()(); (gdb) bt #0 0xb5042e21 in zypp::filesystem::PathInfo::PathInfo(char const*, zypp:: filesystem::PathInfo::Mode) (this=<optimized out>, path=<optimized out>, initial=<optimized out>) at /usr/src/debug/libzypp-16.4.3/zypp/PathInfo.cc:172 #1 0xb5c448a1 in zypp_get_updates (job=<optimized out>, candidates=..., zypp=...) at pk-backend-zypp.cpp:1254 #2 0xb5c448a1 in backend_get_updates_thread(PkBackendJob*, GVariant*, gpointer) (job=0x81dab198 [PkBackendJob], params=0x81d82608, user_data=0x0) at pk-backend-zypp.cpp:2297 #3 0x800989f4 in pk_backend_job_thread_setup (thread_data=0x81d10e88) at pk- backend-job.c:813 #4 0xb72ffa4a in g_thread_proxy (data=0x81dafcc0) at gthread.c:784 #5 0xb71d0354 in start_thread (arg=0xb31ceb40) at pthread_create.c:456 #6 0xb70f7c86 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:110

We can see the stack smashing happened in libzypp-16.4.3/zypp/PathInfo.cc:172. I looked the implementation of PathInfo class, and found it calls xstat64() somehow in this 32-bit machine, which is quite odd. @Dominique Could you please cc someone who maintains libzypp to help look at this? Thanks. -- You are receiving this mail because: You are on the CC list for the bug.