Re: [systemd-devel] Configurability for systemd logging API
>> I find that the change acceptance is unclear for fine-tuning of this software >> also around message log programming interfaces. >> Which design approaches do you find acceptable for further considerations? > > Sorry, I really can't follow. How do you generally think about any further fine-tuning of function calls for logging purposes? > If you post a patch we can take it from there. My suggestion is not ready yet to be transformed into this format. Would it make sense to extend logging parameters for the software build system? Which extensions can be integrated into a build script like "configure.ac"? Regards, Markus ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Configurability for systemd logging API
>> Such messages correspond to specific data structures. >> * The log origin and log level are repeated there while the recorded >> information might occasionally not be detailed enough. >> I find that such details can be better handled by the software build >> system. … > I appreciate you wanting to help, but this is not helpful. Thanks for your feedback. > Please post patches if you have suggestions for improvements. I find that the change acceptance is unclear for fine-tuning of this software also around message log programming interfaces. Which design approaches do you find acceptable for further considerations? Regards, Markus ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Configurability for systemd logging API
Hello, Programs from the systemd software library output also some log messages as it is usual for such server applications. Such messages correspond to specific data structures. * The log origin and log level are repeated there while the recorded information might occasionally not be detailed enough. I find that such details can be better handled by the software build system. * The involved text repetition results in improvement possibilities depending on preferred design directions. Some substrings could be eventually shared between message variants if this aspect can be selected as an optimisation goal for the corresponding generation of executable software. https://en.wikipedia.org/wiki/Longest_common_subsequence_problem Regards, Markus ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Clarification around a segmentation fault from an udevd worker
> This is *very* strange. The 'format' parameter should not contain that
> "%s:%s:%d" prefix at all, as this cannot work of course because the
> argument list doesn't match.
I guess that I wonder also about one of my own programming mistakes here.
> Which version of systemd are you based on?
last commit: 6ad6d61f9ddd58983b075e4fbece30bae46fac37
> Do you have *any* local modifications in your tree?
Yes. - It seems that I was bitten by a format string mismatch during
an attempt to display a few more implementation details for my needs.
diff --git a/src/libsystemd/sd-device/device-private.c
b/src/libsystemd/sd-device/device-private.c
index 2e60433..b5a31ec 100644
--- a/src/libsystemd/sd-device/device-private.c
+++ b/src/libsystemd/sd-device/device-private.c
@@ -1076,7 +1076,7 @@ int device_update_db(sd_device *device) {
goto fail;
}
-log_debug("created %s file '%s' for '%s'", has_info ? "db" : "empty",
+log_debug("%s:%s:%d: created %s file '%s' for '%s'", has_info ? "db" :
"empty", __FUNCTION__, __FILE__, __LINE__,
path, device->devpath);
return 0;
Should my compiler "gcc 5.2.0" be able to detect and warn about misplaced
parameters in such an use case?
Regards,
Markus
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Clarification around a segmentation fault from an udevd worker
> This should usually generate a coredump.
I have regenerated the current software on my test system.
last commit: 6ad6d61f9ddd58983b075e4fbece30bae46fac37
Sonne:/home/elfring/Projekte/Bau/systemd # systemctl stop systemd-udevd.service
systemd-udevd-kernel.socket systemd-udevd-control.socket && gdb ./systemd-udevd
GNU gdb (GDB; openSUSE Factory) 7.9
…
(gdb) set follow-fork-mode child
(gdb) set detach-on-fork off
(gdb) run --debug
Starting program: /home/elfring/Projekte/Bau/systemd/systemd-udevd --debug
…
restoring old watch on '/dev/dm-12'
adding watch on '/dev/dm-12'
seq 2638 queued, 'add' 'usb'
…
(gdb) set print inferior-events on
(gdb) info inferiors
Num Description Executable
* 3/usr/lib/udev/mtp-probe
2process 5759 /home/elfring/Projekte/Bau/systemd/systemd-udevd
1process 5751 /home/elfring/Projekte/Bau/systemd/systemd-udevd
(gdb) inferior 2
(gdb) continue
Continuing.
'/usr/lib/udev/mtp-probe /sys/devices/pci:00/:00:02.0/usb3/3-2 3
3'(out) '0'
Process '/usr/lib/udev/mtp-probe /sys/devices/pci:00/:00:02.0/usb3/3-2
3 3' succeeded.
2638:udev_event_execute_rules:/home/elfring/Projekte/systemd/lokal/src/udev/udev-event.c:896:
add for 3-2
2638:udev_event_execute_rules:/home/elfring/Projekte/systemd/lokal/src/udev/udev-event.c:905:
owner set
2638:udev_node_add:/home/elfring/Projekte/systemd/lokal/src/udev/udev-node.c:342:
handling device node '/dev/bus/usb/003/003', devnum=c189:258, mode=0664,
uid=0, gid=7
2638:node_permissions_apply:/home/elfring/Projekte/systemd/lokal/src/udev/udev-node.c:281:
set permissions /dev/bus/usb/003/003, 020664, uid=0, gid=7
2638:node_symlink:/home/elfring/Projekte/systemd/lokal/src/udev/udev-node.c:84:
creating symlink '/dev/char/189:258' to '../bus/usb/003/003'
Program received signal SIGSEGV, Segmentation fault.
0x76fefc78 in vfprintf () from /lib64/libc.so.6
(gdb) bt full
#0 0x76fefc78 in vfprintf () from /lib64/libc.so.6
No symbol table info available.
#1 0x77016f39 in vsnprintf () from /lib64/libc.so.6
No symbol table info available.
#2 0x5559ac64 in log_internalv (level=7, error=0, file=0x556118a0
"/home/elfring/Projekte/systemd/lokal/src/libsystemd/sd-device/device-private.c",
line=1080, func=0x556124c0 <__func__.9471> "device_update_db",
format=0x55611f40 "%s:%s:%d: created %s file '%s' for '%s'",
ap=0x7fffd760)
at /home/elfring/Projekte/systemd/lokal/src/basic/log.c:662
_saved_errno_ = 0
buffer = "db:device_update_db:1432426656: created ", '\000' ,
"\221\367\275K2\375\244\300\317\377\377\377\177\000\000\241\252YUUU\000\000\000\000\000\000\000\000\000\000êYUUU\000\000\300\341_UUU\000\000\000\000\000\000\000\000\000\000\300\341_UUU\000\000\000\000\000\000\211\003\000\000
\332_UUU\000\000\000\000\000\000"...
#3 0x5559ad9b in log_internal (level=7, error=0, file=0x556118a0
"/home/elfring/Projekte/systemd/lokal/src/libsystemd/sd-device/device-private.c",
line=1080,
func=0x556124c0 <__func__.9471> "device_update_db",
format=0x55611f40 "%s:%s:%d: created %s file '%s' for '%s'")
at /home/elfring/Projekte/systemd/lokal/src/basic/log.c:679
ap = {{gp_offset = 48, fp_offset = 48, overflow_arg_area =
0x7fffd860, reg_save_area = 0x7fffd780}}
r = 21845
#4 0x555f522c in device_update_db (device=0x5567bb20) at
/home/elfring/Projekte/systemd/lokal/src/libsystemd/sd-device/device-private.c:1079
_level = 7
_e = 0
id = 0x5567a740 "c189:258"
path = 0x7fffd870 "/run/udev/data/c189:258"
f = 0x556526a0
path_tmp = 0x5566e770 "/run/udev/data/.#c189:258gYzL5N"
has_info = true
r = 0
__PRETTY_FUNCTION__ = "device_update_db"
__func__ = "device_update_db"
__FUNCTION__ = "device_update_db"
#5 0x555cb3cf in udev_device_update_db (udev_device=0x55638560) at
/home/elfring/Projekte/systemd/lokal/src/libudev/libudev-device-private.c:48
r = 21845
__PRETTY_FUNCTION__ = "udev_device_update_db"
#6 0x5556c924 in udev_event_execute_rules (event=0x55638df0,
timeout_usec=18000, timeout_warn_usec=6000,
properties_list=0x556380c0,
rules=0x55638500) at
/home/elfring/Projekte/systemd/lokal/src/udev/udev-event.c:939
dev = 0x55638560
__func__ = "udev_event_execute_rules"
__FUNCTION__ = "udev_event_execute_rules"
#7 0x55563264 in worker_spawn (manager=0x55638080,
event=0x5566ea30) at
/home/elfring/Projekte/systemd/lokal/src/udev/udevd.c:450
udev_event = 0x55638df0
fd_lock = -1
dev = 0x55638560
rtnl = 0x0
fd_signal = 4
ep_monitor = {events = 1, data = {ptr = 0xb, fd = 11, u32 = 11, u64 =
11}}
mask = {__val = {18446744067267100671, 18446744073709551615 }}
fd_monitor = 11
fd_ep =
Re: [systemd-devel] Completion of error handling
> I have no understanding of Coccinelle. I do not understand what you > are saying. The application of a few scripts in the semantic patch language can occasionally help to improve some software, can't it? Now I'll try again to present more detailed source code analysis results according to specific software metrics. I assumed that each source file (*.c) provides only functions which unique names. ╔╤╗ ║│║ ║│ incidents║ ║ overview │ │║ ║│ total │ ≠ 0║ ║│ │ ≠ NULL ║ ╟┼───┼╢ ║│ │║ ║ non-empty │ │║ ║ return │ 20633 │ 15477 ║ ║ statements │ │║ ║│ │║ ╟┼───┼╢ ║│ │║ ║ non-void │ 5990 │ 5183 ║ ║ functions │ │║ ║│ │║ ╚╧═══╧╝ Does such a table indicate that there are some function implementations left over which will provide only the return value "zero" (or "NULL")? A few specific examples: * client_timeout_resend_expire * config_parse_memory_limit * transfer_on_log * udev_rules_unref * writer_free Is this information worth for further considerations? Regards, Markus ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Creation of additional links for selected devices
Hello, I would like to clarify the combination of commands like "udevadm control -p" and "udevadm trigger" a bit more. How do device properties differ from attributes in this use case? I imagine that additional properties can be set before a corresponding addition of matching devices would be triggered. Would you like to share any more experiences around the fine-tuning of such settings and their reuse for the generation of symbolic links by udev rules? Regards, Markus ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Clarification around a segmentation fault from an udevd worker
>> Jul 26 15:03:38 Sonne systemd-udevd[5347]: auid=1000 uid=0 >> gid=0 ses=1 pid=5347 comm="systemd-udevd" >> exe="/home/elfring/Projekte/Bau/systemd/systemd-udevd" sig >> Jul 26 15:03:38 Sonne kernel: systemd-udevd[5347]: segfault at 438 ip >> 76fefc78 sp 7fffc6b0 error 4 in >> libc-2.21.so[76fa7000+196000] > > Does: > $ addr2line -e home/elfring/Projekte/Bau/systemd/systemd-udevd > 0x76fefc78 > > show something? Not the information we are interested in. Sonne:~ # addr2line -e /home/elfring/Projekte/Bau/systemd/systemd-udevd 0x76fefc78 ??:0 Is such a display useful for a corresponding problem analysis? Regards, Markus ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Clarification around a segmentation fault from an udevd worker
> It should print the backtrace with the location where the error happened. Unfortunately, no. Sonne:/home/elfring/Projekte/Bau/systemd # systemctl stop systemd-udevd.service systemd-udevd-kernel.socket systemd-udevd-control.socket && gdb systemd-udevd … worker [5347] terminated by signal 11 (Segmentation fault) worker [5347] failed while handling '/devices/pci:00/:00:02.0/usb3/3-2/3-2:1.0' udev_monitor_send_device:/home/elfring/Projekte/systemd/lokal/src/libudev/libudev-monitor.c:770: passed device to netlink monitor 0x55671520 ^CUnloaded link configuration context. [Inferior 1 (process 5339) exited normally] (gdb) bt full No stack. Sonne:~ # journalctl -xe … Jul 26 15:03:38 Sonne systemd-udevd[5347]: auid=1000 uid=0 gid=0 ses=1 pid=5347 comm="systemd-udevd" exe="/home/elfring/Projekte/Bau/systemd/systemd-udevd" sig Jul 26 15:03:38 Sonne kernel: systemd-udevd[5347]: segfault at 438 ip 76fefc78 sp 7fffc6b0 error 4 in libc-2.21.so[76fa7000+196000] … Do I need to be more concerned about an "error 4"? Regards, Markus ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Completion of error handling
> No, nothing needs more discussion or attention in the context of systemd. I disagree here. - I would appreciate if return value ignorance can be still reduced at more source code places. Do you distinguish any update candidates which belong to a subsystem in this software? > None of the above seems contain anything useful or is expected to > contribute anything useful in the future. More time will pass by until the adoption of higher level tools might increase. Changes can be introduced by file formats which need some manual work. Would it be nice if a software evolution pattern should only be specified once and can be applied to a wide range of source files then automatically? > This is a development mailing list, we discuss patches and actual code, > and not vague questions like you ask. Do any updates need a bit of consensus before big efforts will be invested. Will any software developer (besides me) become interested to integrate a patch in the format of an AspectC++ file or a SmPL script for example? Regards, Markus ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Clarification around a segmentation fault from an udevd worker
Hello, I would like to clarify the setting of device file permissions for my needs. So I extended the debug output at some source code places to see also better which lines are executed during my tests. I built these extensions for calls of the function "log_debug" on the current source files (last commit: 3460810e8c61986a4605ad80c9e4805eb95cb5a1) with the software "GCC 5.2.0" on my openSUSE Tumbleweed system. I am experimenting a bit with this fresh server program. Sonne:~ # systemctl stop systemd-udevd.service systemd-udevd-kernel.socket systemd-udevd-control.socket && /home/elfring/Projekte/Bau/systemd/systemd-udevd --debug Now I wonder about an error message like the following. … adding watch on '/dev/dm-0' … seq 2633 forked new worker [19879] seq 2633 running IMPORT builtin 'usb_id' /usr/lib/udev/rules.d/40-libgphoto2.rules:9 unable to access usb_interface device of '/sys/devices/pci:00/:00:02.0/usb3/3-2/3-2:1.0' IMPORT builtin 'usb_id' returned non-zero IMPORT builtin 'hwdb' /usr/lib/udev/rules.d/50-udev-default.rules:11 worker [19879] terminated by signal 11 (Segmentation fault) worker [19879] failed while handling '/devices/pci:00/:00:02.0/usb3/3-2/3-2:1.0' … I would appreciate your advices. I hope that I do not need to extend all log messages with additional information details. It would be nice if I could find the failure place easier within a session with the help of a graphical debugger, wouldn't it? Regards, Markus ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Completion of error handling
> We accept contributions only in git-format-patch frmatted patches, > best via github PRs. The higher level patch formats I'm trying to make you aware of will also result in file changes which can be integrated by this content management interface depending on your general acceptance for corresponding software evolution. Examples: * Scripts in the semantic patch language can be processed for occasional patch generation by the Coccinelle software. http://coccinelle.lip6.fr/papers.php * Aspect files could be transformed during an enhanced build process by the AspectC++ software. http://aspectc.org/Publications.php >> Would you like to give thoughts for the extension of the software development >> toolbox a chance? > > I am sorry, your questions are not useful, because too generic. I hope that the software situation can also be improved by development methodology and technology you are more familiar with at the moment. Would you like to reopen a specific bug report for example? https://github.com/systemd/systemd/issues/644 Update candidates: * How do you think about to look at calls for functions from the application programming interface "POSIX threads" again? * Does the usage of file output functions need another look? Regards, Markus ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Completion of error handling
> I have no understanding of Coccinelle. This software provides the tool "spatch" which lets you specify transformations for C source code in a similar way you are used to already by the reuse of unified context diffs. http://coccinelle.lip6.fr/ I assume that you have eventually noticed specific updates on Linux source files which were automatically generated by this technology. https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/coccinelle.txt?id=refs/tags/v4.1.3 > I do not understand what you are saying. How do you think about to try the shown small source code analysis script out so that you can see from a generated patch directly where another look might be useful? > Generally, please be specific, provide patches. I suggest to consider additional "patch formats" as a better preparation for software improvements. The Coccinelle software concentrates on the support for collateral evolutions. A specific update suggestion can be written as "a diff script". Each diff targets only a concrete kind of software evolution. But there are methodologies evolving which support the encapsulation of cross-cutting concerns directly. Such known concerns are for example: * Logging * Error detection and corresponding exception handling Would further considerations be acceptable around a tool like "AspectC++"? http://aspectc.org/ > We are much more interested in actual technical contribution, > much less in just talking about stuff. I propose to integrate higher level algorithms and procedures into the software build process so that some manual software maintenance tasks can be reduced. Would you like to give thoughts for the extension of the software development toolbox a chance? Regards, Markus ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Completion of error handling
> We are regularly checking the systemd sources with coverity and the
> llvm/clang analyzer.
I hope that I may look also into a corresponding web interface.
https://scan.coverity.com/projects/350
I found a few update candidates by a web search.
https://github.com/systemd/systemd/issues/644
An analysis script can point more source code places out for
further considerations.
Would you like to care for corresponding open issues?
>> I wonder also about the status of some function implementations
>> which return zero (or NULL) but no other value.
>
> So, what precisely are you wondering about?
How do you think about to look at places once more which can be found
with a small script like the following with the help of the semantic
patch language (and the Coccinelle software)?
@show_zero_returning_functions@
expression express;
identifier work;
type return_type;
@@
*return_type work(...)
{
<+...
(
return
* express
;
...
return
(
* 0
|
* NULL
)
;
|
return
(
* 0
|
* NULL
)
;
)
...+>
}
Will such function implementations ever return also an error code?
> Also, on github, you keep posting stuff that looks like you
> are a bot.
I admit that I dare to repeat some feature requests and bug reports.
I hope that we can avoid further captcha games for a constructive
discussion on software development issues.
I contributed a bit to free software. I assume that you might find a few
of these improvements a bit useful, don't you?
Regards,
Markus
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Completion of error handling
Hello, I would like to continue the clarification of open issues around a topic like "Completion of error handling". https://github.com/systemd/systemd/issues/644 I hope that the amount of unchecked return values can be reduced further in affected source files by the reuse of dedicated software development tools. Which source code analysis approaches would you like to reconsider once more? I wonder also about the status of some function implementations which return zero (or NULL) but no other value. Are you interested to clarify corresponding details a bit more? Regards, Markus ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
